An Illustrated Guide to OAuth and OpenID Connect
developer.okta.com
developer.okta.com
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.
"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.
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.
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..
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.
Your example includes two separate OAuth/OIDC flows. Dropbox as the client to Google, and the camera app as a client to Dropbox.
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?
My day job is building authentication systems, and I barely trust myself to do it right.
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.
Any recommended reading for biting the bullet?
- 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.
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.
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).
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.
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.
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 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.
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
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.
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.
(I know the team behind that product.)
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.
They know what they are doing better than I do and their current pricing suits my needs fine.
$2 per user of your API? How can any company afford that?
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 pricing of Auth0 would never work out (our accounts are free and no one is paying us per account directly) for us.
Not familiar with the other companies, but auth0 has some pretty nifty bells and whistles. I'm sure the others do as well
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.
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.
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.
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.
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.
What you're doing is an absurd straw man, please don't behave like that.
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."