Understanding OAuth2 and OpenID Connect • Hacker News Board

Re: Understanding OAuth2 and OpenID Connect

#21

Post by noneeeed » Sun, Sep 06, 2020, 5:30 PM UTC

candiddevmike wrote: post #19

May be worth mentioning--JWTs are not part of the OAuth. They're certainly used together quite a bit, but you can absolutely use regular session tokens too. I say this as someone who thought JWT was a core part of OAuth and it only added to the perceived complexity of the implementation.

Yeah, I've run into this recently while adding SCIM support to our system. I had to reread the RFCs and docs repeatedly to reassure myself that JWTs were not actually a requirement for the OAuth2 bearer token. It's complete overkill for what we need but the implementation lib I was trying to use assumes it and it was really complicating things unnecessarily.

Re: Understanding OAuth2 and OpenID Connect

#22

Post by deathanatos » Sun, Sep 06, 2020, 5:32 PM UTC

candiddevmike wrote: post #19

May be worth mentioning--JWTs are not part of the OAuth. They're certainly used together quite a bit, but you can absolutely use regular session tokens too. I say this as someone who thought JWT was a core part of OAuth and it only added to the perceived complexity of the implementation.

> May be worth mentioning--JWTs are not part of the OAuth /OIDC standard.

JWTs are a part of the OIDC standard; from the standard itself[1],

> The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT) [JWT].

But your comment sounds like you're conflating OAuth & OIDC. (It is true for OAuth that you're not required to use JWTs.)

[1]: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...

Re: Understanding OAuth2 and OpenID Connect

#23

Post by candiddevmike » Sun, Sep 06, 2020, 5:34 PM UTC

deathanatos wrote: post #22

candiddevmike wrote: post #19

May be worth mentioning--JWTs are not part of the OAuth. They're certainly used together quite a bit, but you can absolutely use regular session tokens too. I say this as someone who thought JWT was a core part of OAuth and it only added to the perceived complexity of the implementation.

> May be worth mentioning--JWTs are not part of the OAuth /OIDC standard. JWTs are a part of the OIDC standard; from the standard itself[1], > The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, an…

My bad, yes I meant only OAuth.

Re: Understanding OAuth2 and OpenID Connect

#24

Post by sjroot » Sun, Sep 06, 2020, 5:41 PM UTC

the_af wrote: post #20

sjroot wrote: post #7

Earlier quoted context omitted.

The implicit grant returns an access token directly upon authorization being granted. By removing the additional network request, it can make your system vulnerable via manipulation of redirect URLs. if you’re implementing an OAuth 2 server, you can address this by validating the provided redirect URLs, but you should be doing that regardless. My advice is to just always use the auth code grant with the PKCE extensio…

Oh, I wasn't clear: I understand the implicit grant and I indeed worked on the implementation of an authorization server in a past job (we validated redirect URLs, indeed!). My point is that OAuth flows are confusing enough for a beginner that it's important to explain why seemingly unnecessary hoops are there. This article doesn't (as far as I can see).

Yeah, I gathered you knew what you were talking about after I had already posted my comment lol. Just left it up in case any others have that question. :D

Re: Understanding OAuth2 and OpenID Connect

#25

Post by heliodor » Sun, Sep 06, 2020, 6:19 PM UTC

taosx wrote: post #9

I have wasted so much time on oAuth2 and OIDC the past month that I'm building a SaaS around it. (not wasted but took away time from the business) I would have really liked to use auth0 or other authn services but not a fan of lock-in platforms, I want to export my db without enterprise plans. The pricing model I'm thinking of is a pay per usage + a commission of the total usage per month. Thank you @sjroot

Along these lines, I've released django-allauth-sso to provide a single sign-on package that sits atop the popular django-allauth python package.

https://github.com/HostedMetrics/django-allauth-sso

Hope folks find it useful!

Re: Understanding OAuth2 and OpenID Connect

#26

Post by heliodor » Sun, Sep 06, 2020, 6:28 PM UTC

sjroot wrote: post #6

Are you implementing OAuth 2 or interested in learning more? I would highly recommend combing through the OAuth 2.1 spec [1] as it incorporates the “best practices” that were added to 2.0 through additional RFCs. [1] https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

And here's a decent intro that de-mystifies things for those who feel very confused: https://youtu.be/996OiexHze0

Re: Understanding OAuth2 and OpenID Connect

#27

Post by the_arun » Sun, Sep 06, 2020, 6:40 PM UTC

taosx wrote: post #9

I have wasted so much time on oAuth2 and OIDC the past month that I'm building a SaaS around it. (not wasted but took away time from the business) I would have really liked to use auth0 or other authn services but not a fan of lock-in platforms, I want to export my db without enterprise plans. The pricing model I'm thinking of is a pay per usage + a commission of the total usage per month. Thank you @sjroot

We too are building a SaaS product with billing over OAuth2. Here is our product page - https://formfly.intuit.com. We are not using OIDC. What are you building @taosx? and how are you using OIDC?

Re: Understanding OAuth2 and OpenID Connect

#28

Post by the_arun » Sun, Sep 06, 2020, 6:46 PM UTC

ratiolat wrote: post #3

The main confusion probably comes from the name Oauth, which seems to suggest that it is about Single Sign On/authentication, while in reality it's about granting site A access to your data at site B.

OAuth is for authorization. OAuth scope defines the permissions. Authentication is outside OAuth

Re: Understanding OAuth2 and OpenID Connect

#29

Post by caseysoftware » Sun, Sep 06, 2020, 7:16 PM UTC

tasogare wrote: post #13

sjroot wrote: post #8

Earlier quoted context omitted.

> That’s what Oauth is though. Splitting hairs but no, Oauth has nothing to do with authentication. An introductory article like this should address the distinction between authentication and authorization in the first section IMO.

> the distinction between authentication and authorization Distinction which is totally useless in practice as you certainly won’t have authorization without authentication.

The distinction is irrelevant if you just consider that authorization (authZ) always happens after authentication (authN) but it is important when you realize that different components/systems/protocols might be used in each.

At that point, the separation is more about capabilities/responsibilities than "does it happen?"

(This is what I do in my day job.)

Re: Understanding OAuth2 and OpenID Connect

#30

Post by gavinray » Sun, Sep 06, 2020, 7:42 PM UTC

ayewo wrote: post #14

sjroot wrote: post #11

Earlier quoted context omitted.

Nice, good luck! My advice would be to offer something very opinionated to limit the chance that something is rolled out incorrectly. That and preventing lock-in are two big requirements IMO. I’m doing something somewhat similar, happy to exchange notes.

What do you think of an open core security product like https://fusionauth.io/ that supports those protocols ?

I know this has nothing to do with the product, but I hung out with their CEO Brian Pontarelli and one of their lead devs (I think his name was Daniel) for an afternoon many years ago. This was before FusionAuth, when they were running under Inversoft. They came to do a lunch and learn + product feedback at the place I was working at then. We kept in touch for a while after.

Really amazing group of people, super genuine.