3 ms·

I played around with consuming a few different OIDC providers as close to the raw APIs as possible (not component libraries or client SDKs) just to try and unde

I played around with consuming a few different OIDC providers as close to the raw APIs as possible (not component libraries or client SDKs) just to try and understand the flow. Each provider implemented the spec subtly differently and caused a massive headache to get working even for just a basic auth code with PKCE flow. I'm still none the wiser on why you'd even want OIDC for most apps. Granted if you have much more complex SSO needs with external IDP integrations and OAuth API stuff etc it can make sense. I don't see why it is preferable over basic forms auth with a cookie. The default answer seems to be to support mobile apps but I'm also none the wiser on why a JWT auth token is preferable to store on device and send with every request vs a cookie. They're both just 'keys' that need to accompany every API request and need to be stored securely. OIDC-by-default seems like overengineering but I appreciate I'm probably missing a critical reason.

mickael-kerjean 3y ago
> why you'd even want OIDC for most apps If you can get away from OIDC, don't touch it. It's only usefull if you don't control the source of users, need to have some seemless login across many apps or if your app is integrated with many other apps for which you need something that work everywhere and that is a standard. OIDC and SAML are the lingua franca when you need that kind of capabilities and those scenario are just the one I've faced, there's a lot more to it > I don't see why it is preferable over basic forms auth with a cookie. Cookie is how you typically persist session on a browser, this is the step that usually goes after you've authenticated / been authorised, the scope of OIDC is purely in the authentication/authorisation and doesn't even specify how you should persist the session. Also the scope of OIDC goes beyond the browser > OIDC-by-default seems like overengineering but I appreciate I'm probably missing a critical reason. By all means, if your use case doesn't need it, don't touch OIDC/SAML it would be like using kubernetes to host your mum wordpress. OIDC and SAML are complicated because SSO is made to fit the need of companies with all sort of use cases that goes beyond simple use case like the one you seem to describe.
trommlp 3y ago
I wholeheartedly agree with your last sentence that is seems overengineered, but one has to assume that there are use cases that warrant such a complex auth scheme. I cannot speak to that as I have never implemented systems of massive scale. However one thing that puts me off is that it slowly becomes the default way of implementing authentication and authorisation at work where our internal (web) services are (at best) used by 10s of people on a given day. Besides the "old" way of auth integrated much better into our existing system landscape while the "new" way requires (in our case) a Keycloak server. Again, all that would be fine if the use cased warranted the complexity, but in my employer's case it does not.
- elevation 3y ago
  A session cookie from app1.domain.com isn’t readable by app2.domain.com. So with plain cookie auth, you have to login to every app individually. Is there a simpler way around this than OIDC? And what if you want to gate your services to only those users who have an org-issued yubikey? With OIDC you can delegate the device check to a single host (your IdP) and if apps speak OIDC they’ll be protected. That means MFA SSO! Is OIDC the wrong tool for this job?
  - trommlp 3y ago
    I assume from what you are describing that OIDC is probably just the right tool for this job. In my problem domain (think internal apps that serve many different purposes with little overlap and a diverse set of users) logging in individually to every single app simply is not an issue, albeit a little annoying). That being said we do use a single authentication backend across all apps, just not one that is capable of OIDC and is thus a lot more limited in what can be achieved with it.
donatj 3y ago
So much this. I work on an educational product, and we support something like 5 or 6 different school OIDC providers and have to maintain a separate implementation for each one. They all use the same base class, but there’s just a stupid amount of variation in how they actually work.
- mooreds 3y ago
  Can you share the names of these OIDC providers? I've worked some with schools and it seems like they all have settled on either Azure AD/Entra or Google, but I'd like to learn more.
  - donatj 3y ago
    Clever, Canvas, Schoology along with Microsoft and Google

mickael-kerjean 3y ago

> why you'd even want OIDC for most apps If you can get away from OIDC, don't touch it. It's only usefull if you don't control the source of users, need to have some seemless login across many apps or if your app is integrated with many other apps for which you need something that work everywhere and that is a standard. OIDC and SAML are the lingua franca when you need that kind of capabilities and those scenario are just the one I've faced, there's a lot more to it > I don't see why it is preferable over basic forms auth with a cookie. Cookie is how you typically persist session on a browser, this is the step that usually goes after you've authenticated / been authorised, the scope of OIDC is purely in the authentication/authorisation and doesn't even specify how you should persist the session. Also the scope of OIDC goes beyond the browser > OIDC-by-default seems like overengineering but I appreciate I'm probably missing a critical reason. By all means, if your use case doesn't need it, don't touch OIDC/SAML it would be like using kubernetes to host your mum wordpress. OIDC and SAML are complicated because SSO is made to fit the need of companies with all sort of use cases that goes beyond simple use case like the one you seem to describe.

trommlp 3y ago

I wholeheartedly agree with your last sentence that is seems overengineered, but one has to assume that there are use cases that warrant such a complex auth scheme. I cannot speak to that as I have never implemented systems of massive scale. However one thing that puts me off is that it slowly becomes the default way of implementing authentication and authorisation at work where our internal (web) services are (at best) used by 10s of people on a given day. Besides the "old" way of auth integrated much better into our existing system landscape while the "new" way requires (in our case) a Keycloak server. Again, all that would be fine if the use cased warranted the complexity, but in my employer's case it does not.

elevation 3y ago
A session cookie from app1.domain.com isn’t readable by app2.domain.com. So with plain cookie auth, you have to login to every app individually. Is there a simpler way around this than OIDC? And what if you want to gate your services to only those users who have an org-issued yubikey? With OIDC you can delegate the device check to a single host (your IdP) and if apps speak OIDC they’ll be protected. That means MFA SSO! Is OIDC the wrong tool for this job?
- trommlp 3y ago
  I assume from what you are describing that OIDC is probably just the right tool for this job. In my problem domain (think internal apps that serve many different purposes with little overlap and a diverse set of users) logging in individually to every single app simply is not an issue, albeit a little annoying). That being said we do use a single authentication backend across all apps, just not one that is capable of OIDC and is thus a lot more limited in what can be achieved with it.

donatj 3y ago

So much this. I work on an educational product, and we support something like 5 or 6 different school OIDC providers and have to maintain a separate implementation for each one. They all use the same base class, but there’s just a stupid amount of variation in how they actually work.

mooreds 3y ago
Can you share the names of these OIDC providers? I've worked some with schools and it seems like they all have settled on either Azure AD/Entra or Google, but I'd like to learn more.
- donatj 3y ago
  Clever, Canvas, Schoology along with Microsoft and Google