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