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 baked webview implementations, browser specific quirks, and limitations on how to call back to the host app which initiated the flow.
Other questions are how do we handle return urls, i.e. return to where we started the login flow from? there isn't a good answer in oidc, unless you use some of the more extreme flows. It becomes tricky to implement without opening yourself to open redirect attacks, which kind of voids the benefits of oidc (that you don't have to handle the complexity of the authentication).
Also there are endless variations of the oidc flow, the most common being code flow, which is pretty much what you describe. But it gets increasingly complex as you have to handle native app login (PKCE pronounced pixie). 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.
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.
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.
Maybe you wanted to embed the login page on your own site (iframe or webview)
Half of the reason to use SSO is that users should not ever enter their credentials on arbitrary web sites.
Otherwise generally agree with the rest of your points. Acquiring a token from a web page and especially authentication from non browser contexts can be excruciatingly difficult. Imagine an idp only providing login through browser prompts, when you are trying to build a CLI that requires login.
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 in practice. The way you get to 4 or 5 levels is if you have organisational dysfunction on top of all this and you are forced to do your logins thru e.g. one or more fed servers owned by a different team in your company (who add even more layers of indirection).
Mostly as a relying party you will be insulated from all the complexity but if you own your oidc server and manage the brokering you will probably have to deal with a lot of edge cases.
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.
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.
Comments
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 baked webview implementations, browser specific quirks, and limitations on how to call back to the host app which initiated the flow.
Other questions are how do we handle return urls, i.e. return to where we started the login flow from? there isn't a good answer in oidc, unless you use some of the more extreme flows. It becomes tricky to implement without opening yourself to open redirect attacks, which kind of voids the benefits of oidc (that you don't have to handle the complexity of the authentication).
Also there are endless variations of the oidc flow, the most common being code flow, which is pretty much what you describe. But it gets increasingly complex as you have to handle native app login (PKCE pronounced pixie). 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.
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.
Half of the reason to use SSO is that users should not ever enter their credentials on arbitrary web sites.
Otherwise generally agree with the rest of your points. Acquiring a token from a web page and especially authentication from non browser contexts can be excruciatingly difficult. Imagine an idp only providing login through browser prompts, when you are trying to build a CLI that requires login.
Isn't the "state" parameter often used for including the return url? Similar to RelayState in SAML2?
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 in practice. The way you get to 4 or 5 levels is if you have organisational dysfunction on top of all this and you are forced to do your logins thru e.g. one or more fed servers owned by a different team in your company (who add even more layers of indirection).
Mostly as a relying party you will be insulated from all the complexity but if you own your oidc server and manage the brokering you will probably have to deal with a lot of edge cases.
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.
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.