An Illustrated Guide to OAuth and OpenID Connect(developer.okta.com)
developer.okta.com
An Illustrated Guide to OAuth and OpenID Connect
https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
78 comments
> In OAuth, you have a server that both 1. knows who a user is (can authenticate them) and 2. can do things on behalf of the user (send emails, provide files).
No! OAuth servers don't necessarily authenticate a user by themselves, and can't "do things" on behalf of the user (or at least, they don't have to). You misunderstand OAuth fundamentals if you think that.
OAuth is all about delegation. You use OAuth when you want a user (resource owner) to be able to delegate "access to a resource" to a registered client (an app or website, normally), without disclosing its credentials to the client directly, simple as that.
The OAuth server doesn't need to know anything about how authentication will be performed, it only has to be configured to redirect to an authentication server when necessary to obtain an authorization grant from the end user.
The authentication method is not defined in the specs because it would be extremely foolish to tie implementations to particular methods of the day for identity proof.
OpenID extends OAuth by defining how identity can be provided to the client (in simplified terms, by defining the format of tokens _and_ an user API so that they can identify users), something that OAuth omitted, causing a lot of confusion (but keeping the spec sane).
No! OAuth servers don't necessarily authenticate a user by themselves, and can't "do things" on behalf of the user (or at least, they don't have to). You misunderstand OAuth fundamentals if you think that.
OAuth is all about delegation. You use OAuth when you want a user (resource owner) to be able to delegate "access to a resource" to a registered client (an app or website, normally), without disclosing its credentials to the client directly, simple as that.
The OAuth server doesn't need to know anything about how authentication will be performed, it only has to be configured to redirect to an authentication server when necessary to obtain an authorization grant from the end user.
The authentication method is not defined in the specs because it would be extremely foolish to tie implementations to particular methods of the day for identity proof.
OpenID extends OAuth by defining how identity can be provided to the client (in simplified terms, by defining the format of tokens _and_ an user API so that they can identify users), something that OAuth omitted, causing a lot of confusion (but keeping the spec sane).
>But neither OpenID nor OAuth specify how to do authentication!
Any good "I barely know how to host a server that responds to requests" level hold-my-hand-through-it tutorials on how to do authentication?
Any good "I barely know how to host a server that responds to requests" level hold-my-hand-through-it tutorials on how to do authentication?
In that case I would recommend using an out of the box solution like Firebase. Don’t do the authentication yourself.
My day job is building authentication systems, and I barely trust myself to do it right.
My day job is building authentication systems, and I barely trust myself to do it right.
I've asked this question a bunch of times before and this is the first time I've gotten any suggestions as concrete as firebase. Thanks a ton. It's super helpful when I don't even know what to google. Previous attempts to google it led to me thinking OAuth and OpenID were out of the box solutions, and I gave up. Like, seriously thanks. Any suggested alternatives I should also look into while I'm at it? (ideally ones that aren't "log in via fb or google")
Yes, OAuth and OpenID Connect are both standardized protocols, so they are effectively abstractions for performing delegated authorization and authentication, respectively. They exist basically to promote best practices and to help promote interoperability between products - mores with OpenID Connect, as OAuth does not really have any profiles of usage attached to it.
You sound like you may be looking for a CIAM solution. Searching for CIAM (a customer identity and access management product) should show you tons of alternatives.
Full disclosure is that my employer sells one of these, PingOne for Customers. To clarify the parent's post, Firebase Auth also has the related Google Cloud Identity Platform - I will say even as someone in this space I don't fully understand the reasoning behind Google selling both of those products, however.
You sound like you may be looking for a CIAM solution. Searching for CIAM (a customer identity and access management product) should show you tons of alternatives.
Full disclosure is that my employer sells one of these, PingOne for Customers. To clarify the parent's post, Firebase Auth also has the related Google Cloud Identity Platform - I will say even as someone in this space I don't fully understand the reasoning behind Google selling both of those products, however.
In practice if you barely know how to host a server that responds to requests, most solutions won’t work for you because they require writing code that assumes you know somewhat more about how it all works.
I would frankly recommend biting the bullet and doing some heavy reading and trial and error. All of the solutions I know only get you out of the business of storing/managing/checking passwords or MFA. They don’t get you out of anything else.
If you just need something quick and dirty and not "best practices", you could configure HTTP based authentication (over HTTPS) through a web server like Apache.
I would frankly recommend biting the bullet and doing some heavy reading and trial and error. All of the solutions I know only get you out of the business of storing/managing/checking passwords or MFA. They don’t get you out of anything else.
If you just need something quick and dirty and not "best practices", you could configure HTTP based authentication (over HTTPS) through a web server like Apache.
Want to know what's crazy? I've stood up a bunch of services and stuff professionally over the last bunch of years, it's just that internal company tools always take care of deployment and security and authentication and exposing them to the world. Yay for efficiency and specialization. Boo for blind spots.
Any recommended reading for biting the bullet?
Any recommended reading for biting the bullet?
The specifics unfortunately depend a lot on what you're protecting. Are you writing an enterprise web app? Consumer web app? Phone app? Desktop app? Blog engine? E-commerce store? Multiple of the above?
How about just a simple personal project I want to only give access to myself and a few friends access to on browser and phone app? User X can access only documents ABC. Users must be logged in. I'm not looking to make a career shift to web dev, but I'd like to be able to build my own cheap toys, basically. While learning interesting and not terrible skills along the way.
Super scratch-notes version:
- Use sendgrid to send emails, it'll be free at your usage
- Make the login form only accept an email address, dont risk saving passwords, display a generic "if you signed up you'll get an email soon" message on submission for all values.
- Whitelist your buddies' emails, send them a link to login with. Ignore the rest.
- The link can be a UUID without the dashes or something similarly sufficiently random (could sha1 hash the time and be good enough for your purposes). yourdomain.com/login/somesufficientlyrandomandlongkey
- Save that key in the DB, that's effectively the password. Delete stuff after a while so they have to re-login.
Feel free to hit me up on Keybase or whatever (details in my profile) if you want to follow up in detail.
- Use sendgrid to send emails, it'll be free at your usage
- Make the login form only accept an email address, dont risk saving passwords, display a generic "if you signed up you'll get an email soon" message on submission for all values.
- Whitelist your buddies' emails, send them a link to login with. Ignore the rest.
- The link can be a UUID without the dashes or something similarly sufficiently random (could sha1 hash the time and be good enough for your purposes). yourdomain.com/login/somesufficientlyrandomandlongkey
- Save that key in the DB, that's effectively the password. Delete stuff after a while so they have to re-login.
Feel free to hit me up on Keybase or whatever (details in my profile) if you want to follow up in detail.
A large part of the confusion is that "OpenID" is, yes, basically just authentication. It's clearly not OAuth.
"OpenID Connect" is basically OAuth though. It even says so on their website: https://openid.net/connect/faq/
>OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications.
They're quite different things, they're just (ab)using the "OpenID" name for brand recognition.
"OpenID Connect" is basically OAuth though. It even says so on their website: https://openid.net/connect/faq/
>OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications.
They're quite different things, they're just (ab)using the "OpenID" name for brand recognition.
What's the point of a an identity provider if it doesn't authenticate the user? Yes, maybe it's valid according to the spec, but that's not what it's designed for. No need to confuse people on theoretical data differences that don't appear in practice.
What's the point of an OAuth provider if it doesn't authenticate the user? I don't mean to be snarky, but this is something that's widely confused on the internet and by making a parallel statement I think this is most clearly indicated.
The fact is that authentication is required for both. My point is that "authentication" isn't a particular of OpenID 2, and focusing on that when explaining it is what's confusing.
For my part I was very confused when researching the two until I learned to mentally flag answers/posts that focused on this as noise.
The fact is that authentication is required for both. My point is that "authentication" isn't a particular of OpenID 2, and focusing on that when explaining it is what's confusing.
For my part I was very confused when researching the two until I learned to mentally flag answers/posts that focused on this as noise.
> But the _3rd party client_ is the one can do things on behalf of the user (post messages on a forum, add details to a map, etc).
How does this part work? It's unclear to me how a web/mobile app should be posting to a forum. It's invoking an API that exists on a server (client-side code is not secure). Perhaps I'm picturing your model wrong..
How does this part work? It's unclear to me how a web/mobile app should be posting to a forum. It's invoking an API that exists on a server (client-side code is not secure). Perhaps I'm picturing your model wrong..
Client here is referring to the server that doesn't manage identities (it's the OpenID client - heavily overloaded vocabulary isn't helping here of course).
Maybe a better example is say you have a Dropbox camera app. You originally created your Dropbox account using "Sign up with Google". You launch the app, and say "show me my photos". Dropbox is the client, Google is the OpenID provider and tells Dropbox who you are, and the thing Dropbox is doing on behalf of "the user who uploaded the photos" is "sending them over the internet to the user asking for them".
The important thing here is Google doesn't have anything to do with photos, all it does is know who you are. The party that can actually do things is Dropbox, who is storing your photos.
Maybe a better example is say you have a Dropbox camera app. You originally created your Dropbox account using "Sign up with Google". You launch the app, and say "show me my photos". Dropbox is the client, Google is the OpenID provider and tells Dropbox who you are, and the thing Dropbox is doing on behalf of "the user who uploaded the photos" is "sending them over the internet to the user asking for them".
The important thing here is Google doesn't have anything to do with photos, all it does is know who you are. The party that can actually do things is Dropbox, who is storing your photos.
No, you're confusing things again.
Your example includes two separate OAuth/OIDC flows. Dropbox as the client to Google, and the camera app as a client to Dropbox.
Your example includes two separate OAuth/OIDC flows. Dropbox as the client to Google, and the camera app as a client to Dropbox.
Something I still don't understand about the OAuth flow is how it's _not_ training users to be more easily phished for actual usernames and passwords. The very first step is "If you are not logged into the third-party, display a login-form from the third-party."
The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.
What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.
The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.
What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.
> The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site
That's exactly right! But with OAuth, when you authenticate, you go directly to the login-form from the third party (assuming here that by third party you mean the party you have an account with)! Ideally, the client (the app you're using) doesn't even know where you (the user, via the user-agent, otherwise known as "browser") went to log in, it only knows the address of the authorization service (which does not need to be the same domain as the actual login server). That's the great thing about OAuth!
But for this to work, authentication must be performed in a reliable browser, hence the importance of the green URL bar in browsers: so you know you really are in the Google login page, not in some phishing website, when you enter your credentials.
That's exactly right! But with OAuth, when you authenticate, you go directly to the login-form from the third party (assuming here that by third party you mean the party you have an account with)! Ideally, the client (the app you're using) doesn't even know where you (the user, via the user-agent, otherwise known as "browser") went to log in, it only knows the address of the authorization service (which does not need to be the same domain as the actual login server). That's the great thing about OAuth!
But for this to work, authentication must be performed in a reliable browser, hence the importance of the green URL bar in browsers: so you know you really are in the Google login page, not in some phishing website, when you enter your credentials.
This is something that the identity provider struggles with. Supporting additional authentication factors can help, although the newer active phishing attacks are causing issues. Certificates, kerberos and webauthn are inherently phishing resistant which mostly solves the problem if you can rely on or leverage them.
You can also do a form of device enrollment/tracking via a cookie. Since a phisher will not have that cookie, the user authentication experience can switch to be more robust. This also typically triggers a notification to the user that a new device or browser was seen.
You also have threat detection technologies outside of cookies, such as looking at IP address geolocation and doing time of flight analysis.
Thats all stuff the identity provider can do. From a user perspective today - check the address bar, and/or use a password manager.
You can also do a form of device enrollment/tracking via a cookie. Since a phisher will not have that cookie, the user authentication experience can switch to be more robust. This also typically triggers a notification to the user that a new device or browser was seen.
You also have threat detection technologies outside of cookies, such as looking at IP address geolocation and doing time of flight analysis.
Thats all stuff the identity provider can do. From a user perspective today - check the address bar, and/or use a password manager.
I like how Okta is referring to their IAM competitors as "flea mail", "yafool", "outlost", and "LOL".
> In the “stone age” days of the Internet ... You simply gave your username and password for one service to another so they could login to your account and grab whatever information they wanted!
I wish we left that in the past. I live in one of the largest financial hubs in the world and all the budgeting apps here still use username/password sharing for bank accounts.
I wish we left that in the past. I live in one of the largest financial hubs in the world and all the budgeting apps here still use username/password sharing for bank accounts.
Seems there's still confusion so I'll copy/paste my old comment:
OAuth 1.0/2.0 are a set of protocols and standards allowing applications to identify users and get access to their data using existing profiles. OAuth is mostly focused around authorization with claims (which are just key-value pairs) and authentication was an afterthought.
OpenID is another standard designed to let people authenticate across the web, launched with a lot of hype in the early web 2.0 days but never took off. OpenID Connect (OIDC) is a new standard based on OAuth 2 + OpenID to provide both authentication and authorization in a single flow.
OIDC/OAuth is all based on tokens, which are JWTs containing a bunch of claims that can be validated against the server that issued them. There are ID tokens (for the user info) and Access tokens (for accessing an API on behalf of that user), but some services like social logins don't provide any access tokens. Other providers might have rate limits, or dont have fine-grained permissions, or you maybe you have completely internal APIs that you need tokens for.
Also this video is a great in-depth walkthrough: https://www.youtube.com/watch?v=996OiexHze0
OAuth 1.0/2.0 are a set of protocols and standards allowing applications to identify users and get access to their data using existing profiles. OAuth is mostly focused around authorization with claims (which are just key-value pairs) and authentication was an afterthought.
OpenID is another standard designed to let people authenticate across the web, launched with a lot of hype in the early web 2.0 days but never took off. OpenID Connect (OIDC) is a new standard based on OAuth 2 + OpenID to provide both authentication and authorization in a single flow.
OIDC/OAuth is all based on tokens, which are JWTs containing a bunch of claims that can be validated against the server that issued them. There are ID tokens (for the user info) and Access tokens (for accessing an API on behalf of that user), but some services like social logins don't provide any access tokens. Other providers might have rate limits, or dont have fine-grained permissions, or you maybe you have completely internal APIs that you need tokens for.
Also this video is a great in-depth walkthrough: https://www.youtube.com/watch?v=996OiexHze0
Awesome!!! I was about to link this video only!
I just watched the video and it was well worth the hour! The "Illustrated Guide" I linked to is like the perfect lead in to this very informative and clear talk.
Anyone got any insight into how Okta are as an IDaaS provider?
I'm trialling their services along side Ping, I'd be interested to here some of your experiences.
So far, I've enjoyed using the Okta API for building our infrastructure against. Especially with their Terraform provider.
I'm trialling their services along side Ping, I'd be interested to here some of your experiences.
So far, I've enjoyed using the Okta API for building our infrastructure against. Especially with their Terraform provider.
I have (some) experience with various idaas providers from a stint in consulting. I'd say I t depends on what you want as an organization.
The Okta apis are decent but (when I used them a few years ago) a second rate citizen from a development standpoint. At least back then they'd advertise functionality but have very limited api support for them.
As a developer I highly prefer Auth0 over any other options (though Okta would probably be my second choice) but especially at enterprise level negotiations it costs significantly more.
Edit: Mind you, I'm not an expert on these. I've just done (or prepared) implementations with some of these products in an enterprise-y setting.
The Okta apis are decent but (when I used them a few years ago) a second rate citizen from a development standpoint. At least back then they'd advertise functionality but have very limited api support for them.
As a developer I highly prefer Auth0 over any other options (though Okta would probably be my second choice) but especially at enterprise level negotiations it costs significantly more.
Edit: Mind you, I'm not an expert on these. I've just done (or prepared) implementations with some of these products in an enterprise-y setting.
Curious if you evaluated FusionAuth: https://fusionauth.io/
(I know the team behind that product.)
(I know the team behind that product.)
Nope, sorry.
And how does it compare to Azure AD?
Does anyone know if there is any significant upside to using IAM services such as okta or auth0 when anyone can readily deploy a IAM service such as keycloak?
That is a very good question as are the answers given.
I think the important take-away from all this is that OAuth and OpenId and what have you are very complicated.
That would seem to be the reason many companies can make a living out of providing them to you.
Now could it all be made easier and simpler to understand somehow? Don't know but that would be great.
I think the important take-away from all this is that OAuth and OpenId and what have you are very complicated.
That would seem to be the reason many companies can make a living out of providing them to you.
Now could it all be made easier and simpler to understand somehow? Don't know but that would be great.
There are different sorts of hard bits IMHO.
OAuth and OpenID Connect can be _conceptually_ hard; you are abstracting authentication and authorization into a protocol and therefore inheriting someone else's model. When that model is presented in the form of a spattering of specifications, understanding and mapping to that model can be really laborious . You also may be doing this as part of a new architecture on your side (e.g. moving from traditional server-side rendered web applications to PWA/SPA apps using APIs).
Strong Authentication and Account Lifecycle Management actually are just a whole lot of logic. Authentication is also something which is continually evolving to stay ahead of attackers. They are hard from the perspective of amount of work required, the distraction from your actual product mission, and the consequence of getting them wrong.
OAuth and OpenID Connect can be _conceptually_ hard; you are abstracting authentication and authorization into a protocol and therefore inheriting someone else's model. When that model is presented in the form of a spattering of specifications, understanding and mapping to that model can be really laborious . You also may be doing this as part of a new architecture on your side (e.g. moving from traditional server-side rendered web applications to PWA/SPA apps using APIs).
Strong Authentication and Account Lifecycle Management actually are just a whole lot of logic. Authentication is also something which is continually evolving to stay ahead of attackers. They are hard from the perspective of amount of work required, the distraction from your actual product mission, and the consequence of getting them wrong.
Another thing that makes it hard I think is that these are all by necessity multi-agent protocols/algorithms. How should we unambiguously describe and specify them? Well verbal verbiage is not very formal.
Maybe something like: https://en.wikipedia.org/wiki/Specification_and_Description_...
What makes this all rather critical is that these are security procedures and, and complexity is the foe of security.
Maybe something like: https://en.wikipedia.org/wiki/Specification_and_Description_...
What makes this all rather critical is that these are security procedures and, and complexity is the foe of security.
Okta at least can act as an SSO provider for Google accounts. I'm not sure how that's done, it seems a bit like black magic. As far as I'm aware Google Apps only allow you to log in with Google accounts otherwise.
Google supports SAML federation:
https://support.google.com/a/answer/60224?hl=en
https://support.google.com/a/answer/60224?hl=en
Whoah, awesome! I guess I was always searching with the wrong terms :/, I did search for "federation" though FWIW. Maybe that's what I should have gone with instead of OpenID with Oidle.
Yup, although calling it black magic isn't far off from the truth. It's why I stick with oauth and let my coworker handle SAML. (They do SAML both directions, which is how we added it to AAD and Windows). It's a bit of a rough implementation though, so we can't do everything we'd like.
Because they know what they do.
Operating keycloak or whatever software correct and securely is something you need experts and someone dedicated. It is not a side job to run a auth service.
Operating keycloak or whatever software correct and securely is something you need experts and someone dedicated. It is not a side job to run a auth service.
This is the exact reasoning I used to justify using Auth0 at my current job, and it’s the same logic I use to justify the maintenance time I put into my own Django library and using Auth0 for all my personal projects from now on.
They know what they are doing better than I do and their current pricing suits my needs fine.
They know what they are doing better than I do and their current pricing suits my needs fine.
> their current pricing suits my needs fine
$2 per user of your API? How can any company afford that?
$2 per user of your API? How can any company afford that?
If you're put off by the $2 per user per month pricing for "Internal Users", then I'd like to point out their docs about Internal vs External users... https://auth0.com/docs/policies/billing#in-our-pricing-what-...
The key line being: "There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee."
Also... This pricing distinction is only noted on their Developer Pro plan.
So for building things that are intended to be used by external users or external paying customers... where you can make the business case for spending at least $0.023 per User per Month (Developer Plan) or $0.28 per User per Month (Developer Pro Plan) then its fine.
If you start to build internal applications and your internal business processes start to rely on your staff logging in using Auth0, then $2 per internal employee per month that uses those tools doesn't seem expensive at all.
The key line being: "There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee."
Also... This pricing distinction is only noted on their Developer Pro plan.
So for building things that are intended to be used by external users or external paying customers... where you can make the business case for spending at least $0.023 per User per Month (Developer Plan) or $0.28 per User per Month (Developer Pro Plan) then its fine.
If you start to build internal applications and your internal business processes start to rely on your staff logging in using Auth0, then $2 per internal employee per month that uses those tools doesn't seem expensive at all.
[deleted]
I'm in the market for the same type of service.
The pricing of Auth0 would never work out (our accounts are free and no one is paying us per account directly) for us.
The pricing of Auth0 would never work out (our accounts are free and no one is paying us per account directly) for us.
(Indeed, that's why we are launching https://www.cloud-iam.com a Keycloak as a Service)
FYI, your TLS certificate is invalid.
Not a good look questioning people who know what they are doing by promoting a service apparently built by someone who does NOT know what they are doing.
They are focusing all of their efforts on specifically IAM services, enabling them to provide features to you that you otherwise wouldn't have the capacity to provide.
Not familiar with the other companies, but auth0 has some pretty nifty bells and whistles. I'm sure the others do as well
Not familiar with the other companies, but auth0 has some pretty nifty bells and whistles. I'm sure the others do as well
It’s a pretty good write up, and it couldn’t have come at a better time, I’m helping my team start using OpenID Connect for a new application and and having a simple human friendly example is huge help.
I'm glad to hear it! Thanks for the feedback!
I’m embarrassed to admit but I’ve spent far too much time reading the minutiae of OAuth2 and OpenID and failing to grasp the big picture until now. This was really well done.
End of the day, an Oauth2 user is just an user admin that creates a child user account for each app, with restricted permissions. Then the app logins with "their" username (client ID) and password (client secret).
Hey! This is David, the author. I'm so glad to hear this post helped you to better understand OAuth and OIDC. Thank you for the feedback!
My biggest issue with OAuth is that it trains user to enter username and password on a page that another site redirected to.
How easy would it be for a website instead of redirecting to https://login.fleamail.com instead redirects to https://login.fleamail.terriblepun.com that has a page that looks exactly like login.fleamail.com
I personally am paranoid about this and check the address and https certificate on the redirected page to make sure it is what I expected, but I am sure the average user does not do that.
How easy would it be for a website instead of redirecting to https://login.fleamail.com instead redirects to https://login.fleamail.terriblepun.com that has a page that looks exactly like login.fleamail.com
I personally am paranoid about this and check the address and https certificate on the redirected page to make sure it is what I expected, but I am sure the average user does not do that.
This is even worse on mobile apps as they typically just show that page in a web view without the ability to even see the URL/cert
It is a nice intro. I like comic style explaination (remember WebAssembly intro from Mozilla). However, do not fool yourself that this is complete or reliable. Some of the statements are borderline and leave wrong impression.
Hi! David, the author here. I'm glad to hear you enjoyed the comic style. This post is a high-level introduction/overview of OAuth/OIDC, so definitely not intended to be complete. However, I would like to understand more what parts you think were "unreliable" or leave the "wrong impression." Thanks!
Would you mind showing where the guide is misleading? I could go over the OIDC spec in tandem with this guide, but it's easier if I know where I have to read more carefully.
Doesn’t render well on mobile. The pictures smash the text to the right instead of moving it below.
how does SAML fit into this? That one confuses me.
It doesn't. SAML is a competing standard with the OpenID standards and is primarily only used for internal SSO within an organization. OIDC/OAuth2 have gotten broader adoption across the web.
I suspect part of this has to with SAML using a more complex scheme and using XML, as opposed to OIDC/OAuth2 primarily being JSON based with very simple permission and identity models.
I suspect part of this has to with SAML using a more complex scheme and using XML, as opposed to OIDC/OAuth2 primarily being JSON based with very simple permission and identity models.
It doesn't. It's an entirely separate protocol and flow. More enterprise and uses XML.
This is terrible. I'd rather have an un-illustrated guide with just the facts.
You have exactly that in the specification. "This is terrible" is unproductive when this is clearly targeted at someone looking for a more high level explanation of OAuth and OpenId.
Not the GP, but “this is terrible” is the kind of feedback I hope to find in hacker news discussions. I want to know how other developers assess the original article.
I find the texts in the comics not very readable. I understand it is meant to show the text as if written by someone on a whiteboard fast, so its a bit like intentionally made less readable, than it could be.
I'd like to see your response to rendaw's comment: "None of these guides really get to the critical difference and relation between OAuth and OpenID."
I'd like to see your response to rendaw's comment: "None of these guides really get to the critical difference and relation between OAuth and OpenID."
I hope to find constructive criticism, ie. it's terrible because of this and that and I would improve it like this and that.
My improvement would be to leave out the condescending comics and describe roles and interactions in a way that's appropriate for adults.
How is this inappropriate for adults? You are free not to like it, but you shouldn't gatekeep others.
I am free to not like it but when I say why I don't like it I'm gatekeeping?
Fair enough. This is what the RFCs are for, which I also prefer.
In OAuth, you have a server that both 1. knows who a user is (can authenticate them) and 2. can do things on behalf of the user (send emails, provide files). A 3rd party client says "I want to send an email via this user, please authorize it" without particularly caring _who_ the user is.
In OpenID Connect you have a server that 1. knows who a user is. But the _3rd party client_ is the one can do things on behalf of the user (post messages on a forum, add details to a map, etc). So the 3rd party, via OpenID, says "tell me who this user is" and then after getting the identity the 3rd party itself decides whether to allow the actions or not.
And you can use them together! Since OpenID is some additional requirements on top of OAuth, you can use it to say "I want to do X and Y on behalf of this user, and while you're at it tell me who they are so I can do authorization for stuff on my side as well."
But neither OpenID nor OAuth specify how to do authentication! Whether that's a username/password, a security token, biometrics, etc. or a combination is totally up to the implementation.
The OpenID spec itself makes three confusing claims in the first 3 sentences:
> OpenID Connect 1.0 is a simple identity layer
Yes!
> It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server
No! Google + co might be Authorization servers, but there's no reason the OpenID provider needs to (or even has the capability) to do any authorization.
> This specification defines the core OpenID Connect functionality: authentication
No! OpenID doesn't specify how to do authentication, and that's not OpenID Connect's core functionality! Providing identity is!
The top SO answer on the difference between OpenID and OAuth:
> OpenID is about authentication (ie. proving who you are), OAuth is about authorisation
And you'll find similar comments all over the internet, Stack Overflow, etc.