4 ms·

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

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

by rendaw 7y ago

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