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

21–30 of 47 posts

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

#21

Post by kjuulh »

robertlagrant wrote: post #17
kjuulh wrote: post #9

Earlier quoted context omitted.

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…

That is probably also the best path if you choose to use oidc as a login / identity solution etc. They do give a lot of stuff out of the box, as well as making it quite easy to integrate with. But at quite the price =D

From my point of view the dangers are implementing parts of this protocol yourself (i.e. becoming one of the parts in the login chain), it requires a surprising amount work to mature, which is why relying on Auth0 which already has been through that is quite nice.

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

#22

Post by plugin-baby »

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.

Why is this getting downvoted? It seems like an interesting point.

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

#23

Post by Jnr »

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.

If you want to add SSO to your software, OIDC is pretty much the standard to go for right now.

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

#24

Post by spapas82 »

Just two days ago I wrote a comprehensive tutorial on how openid connect works using simple http requests to understand the flow: https://spapas.github.io/2023/11/29/openid-connect-tutorial/

It has been written with keycloak as the auth server but should work for any proper openid connect implementation since I used the specification as a guide.

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

#25

Post by robszumski »

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

I really like oauth2proxy for side projects and internal tools.

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

#26

Post by mrweasel »

plugin-baby wrote: post #22
gkoller wrote: post #10

Earlier quoted context omitted.

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.

Why is this getting downvoted? It seems like an interesting point.

Because the CAS protocol is deprecated? It's arguable simpler and easier to deal with and works really well, but not that well supported and that isn't likely do improve at the protocol won't evolve any future.

We're currently in the process of migrating from CAS to OIDC and so far the server side hasn't been much of an issue, but compared to CAS the clients are a little hit and miss. Authentication always works, but claims are annoying.

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

#27

Post by mrweasel »

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.

OpenID no, it's not. OpenID Connect (OIDC) which is built on top of OAuth2, yes, it's very much a thing and much easier to deal with than plain. OAuth2

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

#28

Post by jonbake »

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 argue that the complexity you are describing is inherent in any solution where multi-level sessions are present-- whether the auth mechanisms is OIDC, SAML, or something bespoke. Beyond social logins, there are use cases where multi-level sessions are required. One example is delegating authentication to another IdP. It's possible to use a OIDC client and configure the IdP to not create a session if multi-level sessions are not required.

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

#29

Post by Lucasoato »

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 you think people misuse OIDC, just imagine how much they could fail implementing a AuthN/AuthZ on their own.

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

#30

Post by kjuulh »

jonbake wrote: post #28
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 argue that the complexity you are describing is inherent in any solution where multi-level sessions are present-- whether the auth mechanisms is OIDC, SAML, or something bespoke. Beyond social logins, there are use cases where multi-level sessions are required. One example is delegating authentication to another IdP. It's possible to use a OIDC client and configure the IdP to not create a session if multi-level ses…

Fully agree if you need the session. Then yeah some kind of delegation/abstraction is required. Especially for social/3rd party login.

The missed I've seen is simple that oidc was used on multiple levels to facilitate a login flow and the sessions discarded afterwards

Post reply on HN