15 ms·

An Illustrated Guide to OAuth and OpenID Connect

431 points by jbigelow76 7y ago

rendaw 7y ago
IMO none of these guides really get to the critical difference and relation between OAuth and OpenID. 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.
- Groxx 7y ago
  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/ 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.
- matharmin 7y ago
  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.
  - rendaw 7y ago
    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.
- devicetray0 7y ago
  > 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..
  - rendaw 7y ago
    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.
    - aaronpk 7y ago
      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.
- 6gvONxR4sf7o 7y ago
  >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?
  - munchbunny 7y ago
    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.
    - 6gvONxR4sf7o 7y ago
      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")
      - munchbunny 7y ago
        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.
        6gvONxR4sf7o 7y ago
        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?
- brabel 7y ago
  > 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).
oaiey 7y ago
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.
- runiq 7y ago
  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.
- reverentgeek 7y ago
  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!
tybit 7y ago
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.
- FranOntanaya 7y ago
  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).
- reverentgeek 7y ago
  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!
techdragon 7y ago
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.
- reverentgeek 7y ago
  I'm glad to hear it! Thanks for the feedback!
LilBytes 7y ago
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.
- Huppie 7y ago
  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.
  - mooreds 7y ago
    Curious if you evaluated FusionAuth: https://fusionauth.io/ https://fusionauth.io/ (I know the team behind that product.)
    - Huppie 7y ago
      Nope, sorry.
- yread 7y ago
  And how does it compare to Azure AD?
rumanator 7y ago
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?
- oaiey 7y ago
  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.
  - fgribreau 7y ago
    (Indeed, that's why we are launching https://www.cloud-iam.com https://www.cloud-iam.com a Keycloak as a Service)
    - lifty 7y ago
      FYI, your TLS certificate is invalid.
      - kissgyorgy 7y ago
        A great way to win users trust instantly! :D
      - scient 7y ago
        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.
  - techdragon 7y ago
    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.
shweta_shetye 7y ago
This is very helpful!
- reverentgeek 7y ago
  I'm so glad to hear it :)
pcr0 7y ago
> 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.
- mrmonkeyman 7y ago
  Indeed, let's give our one, only, username and password to a single organisation.
tempodox 7y ago
This is terrible. I'd rather have an un-illustrated guide with just the facts.
- lkschubert8 7y ago
  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.
  - charlieflowers 7y ago
    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.
    - dordoka 7y ago
      I hope to find constructive criticism, ie. it's terrible because of this and that and I would improve it like this and that.
      - tempodox 7y ago
        My improvement would be to leave out the condescending comics and describe roles and interactions in a way that's appropriate for adults.
        matsemann 7y ago
        How is this inappropriate for adults? You are free not to like it, but you shouldn't gatekeep others.
        vraivroo 7y ago
        Please, that's not what gatekeeping is. You might as well start throwing around accusations of racism.
jrockway 7y ago
I like how Okta is referring to their IAM competitors as "flea mail", "yafool", "outlost", and "LOL".
cdelsolar 7y ago
how does SAML fit into this? That one confuses me.
- manigandham 7y ago
  It doesn't. It's an entirely separate protocol and flow. More enterprise and uses XML.
- TrueDuality 7y ago
  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.
JangoSteve 7y ago
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.
- brabel 7y ago
  > 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.
- dwaite 7y ago
  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.
RcouF1uZ4gsC 7y ago
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 https://login.fleamail.com instead redirects to https://login.fleamail.terriblepun.com 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.
- decko 7y ago
  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
manigandham 7y ago
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 https://www.youtube.com/watch?v=996OiexHze0
- vs4vijay 7y ago
  Awesome!!! I was about to link this video only!
  - jbigelow76 7y ago
    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.
pythonwutang 7y ago
Doesn’t render well on mobile. The pictures smash the text to the right instead of moving it below.

431 points by jbigelow76 7y ago

IMO none of these guides really get to the critical difference and relation between OAuth and OpenID. 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.

Groxx 7y ago
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/ 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.
matharmin 7y ago
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.
- rendaw 7y ago
  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.
devicetray0 7y ago
> 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..
- rendaw 7y ago
  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.
  - aaronpk 7y ago
    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.
6gvONxR4sf7o 7y ago
>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?
- munchbunny 7y ago
  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.
  - 6gvONxR4sf7o 7y ago
    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")
    - munchbunny 7y ago
      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.
      - 6gvONxR4sf7o 7y ago
        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?
brabel 7y ago
> 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).

oaiey 7y ago

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.

runiq 7y ago
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.
reverentgeek 7y ago
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!

tybit 7y ago

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.

FranOntanaya 7y ago
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).
reverentgeek 7y ago
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!

techdragon 7y ago

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.

reverentgeek 7y ago
I'm glad to hear it! Thanks for the feedback!

LilBytes 7y ago

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.

Huppie 7y ago
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.
- mooreds 7y ago
  Curious if you evaluated FusionAuth: https://fusionauth.io/ https://fusionauth.io/ (I know the team behind that product.)
  - Huppie 7y ago
    Nope, sorry.
yread 7y ago
And how does it compare to Azure AD?

rumanator 7y ago

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?

oaiey 7y ago
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.
- fgribreau 7y ago
  (Indeed, that's why we are launching https://www.cloud-iam.com https://www.cloud-iam.com a Keycloak as a Service)
  - lifty 7y ago
    FYI, your TLS certificate is invalid.
    - kissgyorgy 7y ago
      A great way to win users trust instantly! :D
    - scient 7y ago
      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.
- techdragon 7y ago
  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.

shweta_shetye 7y ago

This is very helpful!

reverentgeek 7y ago
I'm so glad to hear it :)

pcr0 7y ago

> 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.

mrmonkeyman 7y ago
Indeed, let's give our one, only, username and password to a single organisation.

tempodox 7y ago

This is terrible. I'd rather have an un-illustrated guide with just the facts.

lkschubert8 7y ago
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.
- charlieflowers 7y ago
  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.
  - dordoka 7y ago
    I hope to find constructive criticism, ie. it's terrible because of this and that and I would improve it like this and that.
    - tempodox 7y ago
      My improvement would be to leave out the condescending comics and describe roles and interactions in a way that's appropriate for adults.
      - matsemann 7y ago
        How is this inappropriate for adults? You are free not to like it, but you shouldn't gatekeep others.
        vraivroo 7y ago
        Please, that's not what gatekeeping is. You might as well start throwing around accusations of racism.

jrockway 7y ago

I like how Okta is referring to their IAM competitors as "flea mail", "yafool", "outlost", and "LOL".

cdelsolar 7y ago

how does SAML fit into this? That one confuses me.

manigandham 7y ago
It doesn't. It's an entirely separate protocol and flow. More enterprise and uses XML.
TrueDuality 7y ago
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.

JangoSteve 7y ago

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.

brabel 7y ago
> 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.
dwaite 7y ago
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.

RcouF1uZ4gsC 7y ago

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 https://login.fleamail.com instead redirects to https://login.fleamail.terriblepun.com 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.

decko 7y ago
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

manigandham 7y ago

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 https://www.youtube.com/watch?v=996OiexHze0

vs4vijay 7y ago
Awesome!!! I was about to link this video only!
- jbigelow76 7y ago
  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.

pythonwutang 7y ago

Doesn’t render well on mobile. The pictures smash the text to the right instead of moving it below.