
An Illustrated Guide to OAuth and OpenID Connect - jbigelow76
https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
======
rendaw
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.

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

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

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

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

------
manigandham
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
Awesome!!! I was about to link this video only!

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

------
LilBytes
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
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
Curious if you evaluated FusionAuth:
[https://fusionauth.io/](https://fusionauth.io/)

(I know the team behind that product.)

~~~
Huppie
Nope, sorry.

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

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

~~~
minton
> their current pricing suits my needs fine

$2 per user of your API? How can any company afford that?

~~~
techdragon
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-...](https://auth0.com/docs/policies/billing#in-our-pricing-what-is-the-
difference-between-internal-and-external-users-are-they-different-
technically-)

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.

------
techdragon
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
I'm glad to hear it! Thanks for the feedback!

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

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

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

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

------
shweta_shetye
This is very helpful!

~~~
reverentgeek
I'm so glad to hear it :)

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

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

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

~~~
lkschubert8
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
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
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
My improvement would be to leave out the condescending comics and describe
roles and interactions in a way that's appropriate for adults.

~~~
matsemann
How is this inappropriate for adults? You are free not to like it, but you
shouldn't gatekeep others.

~~~
vraivroo
Please, that's not what gatekeeping is. You might as well start throwing
around accusations of racism.

~~~
matsemann
It's gatekeeping all right. It's a statement about what real adults should
like and not.

What you're doing is an absurd straw man, please don't behave like that.

