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