Live data from Hacker News

Understanding OAuth2 and OpenID Connect

polarsparc.com

11–20 of 65 posts

Re: Understanding OAuth2 and OpenID Connect

#11
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

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.

Re: Understanding OAuth2 and OpenID Connect

#12

Can we update the link to point to the actual article? https://www.polarsparc.com/xhtml/OAuth2-OIDC.html

will be happy to change ... there doesn't a way to edit the post ... any suggestions ?

Email the mods using the address in the “Contact” hyperlink at the bottom of this page: hn@ycombinator.com.

Re: Understanding OAuth2 and OpenID Connect

#13
post #8

Earlier quoted context omitted.

That's what Oauth is though. Oauth is NOT a single sign-on technology, it's about granting access to data across services. OpenID is a single sign-on protocol built on top of Oauth.

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

Re: Understanding OAuth2 and OpenID Connect

#14
post #11
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

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 ?

Re: Understanding OAuth2 and OpenID Connect

#15
post #14
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’ve never heard of FusionAuth but after a quick glance it seems interesting. Generally, I think these standards are worth knowing even if you do decide to use a managed offering.

Also worth mentioning is ORY Hydra.

Re: Understanding OAuth2 and OpenID Connect

#16
post #8

Earlier quoted context omitted.

That's what Oauth is though. Oauth is NOT a single sign-on technology, it's about granting access to data across services. OpenID is a single sign-on protocol built on top of Oauth.

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

Was my comment unclear? "Oauth is NOT single sign-on" single sign-on = authentication. "sharing data across services" = authorizing your data from service A to be used in service B.

Re: Understanding OAuth2 and OpenID Connect

#17
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.

Somewhat. One key “feature” of OAuth is that it completely omits the authentication process.

Re: Understanding OAuth2 and OpenID Connect

#18
post #14
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 ?

Open core..wouldn't that mean the core product being open source..from what I'm seeing on github only some components are open source. By that example I would also call auth0 open core.

Anyways, seems interesting.

Re: Understanding OAuth2 and OpenID Connect

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

Re: Understanding OAuth2 and OpenID Connect

#20
post #7
post #4

The article briefly mentions that the Implicit Grant is a less secure and more simplified version of the Authorization Code grant, but then it doesn't elaborate (or it's possible I missed that bit). In an introductory article such as this, I think it's important to explain why it's less secure -- otherwise the Authorization Code grant seems like an unnecessary complication.

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).
Post reply on HN