Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy to use OpenID Connect client and server library written for Go

github.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Easy to use OpenID Connect client and server library written for Go

#11

Post by kjuulh »

jarym wrote: post #6
kjuulh wrote: post #4

Having built and worked with a variety of oidc implementations. It is an incredibly misused technology, while it initially can be easy to integrate into your app. It increases the complexity of the app to a surprising degree. Now suddenly your little webapp have to handle how various devices handle redirects to external sites, receives callbacks. And all the weird ways oidc implementations uses cookies, handles retur…

I’d agree that layers of OIDC should be an anti-pattern but aside from that my experience with OIDC (developing and running it in production) has been nothing short of amazing. Before OIDC it we had (mostly) SAML but it is a beast by comparison and was limited to enterprise use. The ability of being able to switch auth out with another identity provider with such ease has been nothing short of a blessing. Yes some ov…

MitID (national provider login) in Denmark, is about 2 layers of oidc in of itself (normal oidc and an oauth2). Plus whatever the consumers already have, which is often 1 or 2 as well. They're often used as a layer of abstraction which is a gross misuse of the technology.

As I mentioned previously using it for social logins by itself, is fine in most situations as they're quite mature. And IMO the best and probably intended use case of the technology and there it works quite well.

Re: Easy to use OpenID Connect client and server library written for Go

#13

Post by EtienneK »

berkes wrote: post #12

Is OpenID still in use much? I come across it less and less. To the point where I get the feeling it's just some legacy implementions that have it, but nothing more.

This is for OpenID Connect, which is still widely used almost everywhere. OpenID (not Connect), was its precursor and never really widely adopted.

Re: Easy to use OpenID Connect client and server library written for Go

#14

Post by kjuulh »

xyzzy123 wrote: post #8
harha_ wrote: post #5

Earlier quoted context omitted.

how various devices handle redirects to external sites Isn't a simple redirect in the same window enough? Redirect to OIDC provider -> login -> redirect back APP -> get OIDC state from URI params?

You can easily end up nested flows if e.g, your app uses auth0 and the user is a business user whose company is saml federated to Azure, for example. You can quickly get to 3 levels if e.g. your app uses auth0, github login is supported and then the user does social login to github etc. 2 or 3 levels of federation is common. More levels are possible which is bad if you value your sanity but I think (well, hope) rare…

Yep for normal apps it is rare. The debugging sessions I've been in trying to untangle some of these flows gives me the shivers. Oops someone had a huawei with this specific default browser, that doesn't handle url paths?!?, some android webviews versions not handling redirects properly, android apps not being able to handle redirects in a webview if the app is not active.

These are very app specific, but that is just the amount of complexity that is opened up for in some of these flows. Hopefully webauthn / passkey can help reduce some of these. But I doubt it.

Re: Easy to use OpenID Connect client and server library written for Go

#15

Post by kjuulh »

gkoller wrote: post #10
kjuulh wrote: post #4

Having built and worked with a variety of oidc implementations. It is an incredibly misused technology, while it initially can be easy to integrate into your app. It increases the complexity of the app to a surprising degree. Now suddenly your little webapp have to handle how various devices handle redirects to external sites, receives callbacks. And all the weird ways oidc implementations uses cookies, handles retur…

If login/Single Sign On is what you are after you are arguably better off with Central Authentication Service (CAS). It is much simpler. Unfortunately it isn't as widely known or popular.

Yep, this is why I say that oidc is vastly misused. There are much better options out there for implementing good solid, login, session flows. Using oidc as the only tool in the toolbox is a recipe for disaster.

Re: Easy to use OpenID Connect client and server library written for Go

#16

Post by kjuulh »

jarym wrote: post #7
harha_ wrote: post #5

Earlier quoted context omitted.

how various devices handle redirects to external sites Isn't a simple redirect in the same window enough? Redirect to OIDC provider -> login -> redirect back APP -> get OIDC state from URI params?

It should be yes, although I think what the parent was getting at was layers of OIDC where one provider redirects to another and then you get 2 redirects back. I’ve seen it a few time and can only conclude it’s the work of amateurs.

It really is, in some of these flows the single sign on nature of oidc isn't even used, or hacked away. And only used for login. Which is absolutely wild.

Re: Easy to use OpenID Connect client and server library written for Go

#17

Post by robertlagrant »

kjuulh wrote: post #9
harha_ wrote: post #5

Earlier quoted context omitted.

how various devices handle redirects to external sites Isn't a simple redirect in the same window enough? Redirect to OIDC provider -> login -> redirect back APP -> get OIDC state from URI params?

At the most basic yes, but the protocol doesn't describe what the login part is and how that works. Often it implements session using cookies, which given the state you were in previously. Maybe you wanted to embed the login page on your own site (iframe or webview), now the cookies are flagged as third party cookies and blocked in a variety of context. Especially in an app context it becomes a minefield of half bake…

> Using these flows you end up becoming as much an expert in the technology as you would've been just implementing authentication and identity yourself.

I mostly agree with this. The only thing I'd say is that Auth0 when I used it did abstract away at least the different flavours of Oauth2/OIDC, and we just coded against Auth0's implementation.

Which is a crazy situation to find ourselves in as an industry, but there we are.

Re: Easy to use OpenID Connect client and server library written for Go

#18

Post by KronisLV »

I went with using Keycloak for a platform I'm developing right now and it feels like a very overcomplicated enterprise piece of software - it still does work and has the features that I need (notably: an SSO login portal, user registration, password resets and social login), but definitely needed a certain amount of time to configure correctly and had odd bugs, like me needing the following in my reverse proxy configuration:

  SetEnv proxy-initial-not-pooled 1
  SetEnv proxy-nokeepalive 1
otherwise connections would randomly drop. I was looking for other ways to make development a bit easier and also settled on mod_auth_openidc, which is an Apache module that lets it act like a Relying Party and handle lots of the heavy lifting (protecting endpoints, refreshing tokens etc.) for me, and lets me work with just a few headers that are passed to the protected resources: https://github.com/OpenIDC/mod_auth_openidc

It works, but I'm still not happy - I realize that there are many types of attacks that have historically been a problem and that certain OpenID Connect flows try to protect against, in addition to the fact that if I wrote my own security code it'd almost certainly be worse and have vulnerabilities (in the words of Eoin Woods: "Never invent security technology"), and it's a good thing to follow standards... but the whole thing is such a pain. Both OpenID Connect, Keycloak and configuring mod_auth_openidc.

Right now I'm moving permissions/roles back into the app DB, because I don't want to have to work with the Keycloak REST API every time I want to change what a user can or cannot do in the system, in addition to permissions which might only apply conditionally (one user might be related to multiple organizations, having different permissions in the context of each).

Regardless, it's nice that there are more pieces of software out there to choose from! Do manage your expectations when working with OpenID Connect, though.

Re: Easy to use OpenID Connect client and server library written for Go

#19

Post by wismwasm »

kjuulh wrote: post #4

Having built and worked with a variety of oidc implementations. It is an incredibly misused technology, while it initially can be easy to integrate into your app. It increases the complexity of the app to a surprising degree. Now suddenly your little webapp have to handle how various devices handle redirects to external sites, receives callbacks. And all the weird ways oidc implementations uses cookies, handles retur…

While I think auth is hard it is still doable without having to become an expert when it comes to the details. I recently played around with oauth2proxy and nginx and got it working: https://github.com/layandreas/oauth-proxy-example

Re: Easy to use OpenID Connect client and server library written for Go

#20

Post by kjuulh »

wismwasm wrote: post #19
kjuulh wrote: post #4

Having built and worked with a variety of oidc implementations. It is an incredibly misused technology, while it initially can be easy to integrate into your app. It increases the complexity of the app to a surprising degree. Now suddenly your little webapp have to handle how various devices handle redirects to external sites, receives callbacks. And all the weird ways oidc implementations uses cookies, handles retur…

While I think auth is hard it is still doable without having to become an expert when it comes to the details. I recently played around with oauth2proxy and nginx and got it working: https://github.com/layandreas/oauth-proxy-example

It indeed isn't that hard to get something up and running with oidc or oauth.

However, what becomes problematic is handling inherent complexity of whatever the provider you use is. If the OIDC flow is only intended for you or in-house at a company then it is less problematic. But when used by all sorts of people and devices, it will break in all sorts of problematic ways.

But that isn't to say that you shouldn't use the technology it is fantastic at what it does. I.e. handle social identities in the case of oidc, and authorization in the case of oauth

Post reply on HN