8 ms·
Understanding OAuth2 and OpenID Connect
- bitwarrior 6y agoCan we update the link to point to the actual article? https://www.polarsparc.com/xhtml/OAuth2-OIDC.html https://www.polarsparc.com/xhtml/OAuth2-OIDC.html
- bswamina 6y agowill be happy to change ... there doesn't a way to edit the post ... any suggestions ?
- ayewo 6y agoEmail the mods using the address in the “Contact” hyperlink at the bottom of this page: hn@ycombinator.com.
- dang 6y agoOk, changed to that from https://www.polarsparc.com/2020/09/06/oauth2-oidc/ https://www.polarsparc.com/2020/09/06/oauth2-oidc/.
- ratiolat 6y agoThe 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.
- patmorgan23 6y agoThat'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.
- sjroot 6y ago> 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.
- tasogare 6y ago> the distinction between authentication and authorization Distinction which is totally useless in practice as you certainly won’t have authorization without authentication.
- sjroot 6y agoSomewhat. One key “feature” of OAuth is that it completely omits the authentication process.
- caseysoftware 6y agoThe 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.)
- patmorgan23 6y agoWas 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.
- WGH_ 6y ago> OpenID is a single sign-on protocol built on top of Oauth. Note that there's older OpenID (without "Connect"), which, to my knowledge, is more or less dead nowadays, and OpenID Connect, which is indeed built on top of OAuth. Both are indeed SSO, though.
- the_arun 6y agoOAuth is for authorization. OAuth scope defines the permissions. Authentication is outside OAuth
- the_af 6y agoThe 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.
- sjroot 6y agoThe 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 extension. TLDR of that extension: 1) client generates a “secret key” that it sends with the authorization request. 2) server associates that key with the authorization code it returns to the authorized client 3) client must present that key again in order to exchange the authorization code for the access token. Prevents the authorization code from being intercepted and abused.
- the_af 6y agoOh, 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).
- sjroot 6y agoYeah, 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
- anderspitman 6y agoAre any of the big players (ie FAANG) actually using PKCE yet?
- sjroot 6y agoAre 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 https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00
- taosx 6y agoI 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
- sjroot 6y agoNice, 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.
- ayewo 6y agoWhat do you think of an open core security product like https://fusionauth.io/ https://fusionauth.io/ that supports those protocols ?
- sjroot 6y agoI’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.
- taosx 6y agoOpen 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.
- mooreds 6y agoI work for FusionAuth. It's not open core. It's the other way around (open shell?), as you see, @taosx. The docs, client libraries, example apps, and some supporting libs are Apache licensed, but the core is not. We do have a forever free community offering[0], but that's free as in beer, not as in speech. I think it's a great product (that's part of why I joined the company) but don't want any confusion about that. [0]: https://fusionauth.io/pricing https://fusionauth.io/pricing has a list of the options.
- candiddevmike 6y agoMay 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.
- noneeeed 6y agoYeah, 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.
- deathanatos 6y ago> 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#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
- candiddevmike 6y agoMy bad, yes I meant only OAuth.
- user5994461 6y agoYou were correct though, JWT was not part of the OIDC standard. JWT was created separately and added retroactively later as the standard token format.
- mooreds 6y agoThis was a good article. The first section, explaining the reason why OAuth2 is a fit for certain data flow needs, was really strong. I liked the diagram of the flow as that made it clear what all the pieces were. I think that if you need that separation between your resource servers and authorization server, the OAuth dance can be a bit complicated, you can just use a simple api key. But as soon as you start to allow outside access to your systems, I'd suggest using an OAuth server (disclosure, I work for FusionAuth, a free as in beer competitor to Keycloak, Gluu, etc). Additional things that I wish had been in the article: * Don't use implicit flow, use the authorization code grant with PKCE. * Don't use resource owner password flow; it was designed to allow existing systems to bridge into OAuth and shouldn't be used in new systems today. Both the implicit flow and the resource owner password flow are not part of OAuth 2.1--here's a post I wrote about it: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1 https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1 * Also, storing access tokens should be done carefully in the browser (httponly, secure cookies is the best way). If you can't do that, then use a server side proxy to store the access tokens. Otherwise your access tokens might get stolen by code executing in the browser. * OIDC is built on top of OAuth and has a standard set of claims. If you can get by on what OIDC defines, you can switch between identity provider implementations fairly easily.
- bswamina 6y agoThank you very much for the valuable feedback ... very much appreciate and pointers ... this why love to share so can get feedback and pointers for other information may have missed.
- mooreds 6y agoThanks for writing the post and helping people understand the standards better!
- mooreds 6y ago> I think that if you need that separation between your resource servers and authorization server, ... Ack, this should have been I think that if you do not need that separation between your resource servers and authorization server, ...
- archsurface 6y agoI look forward to reading this, because I'm currently unconvinced it is possible.
- bogomipz 6y agoThis was a really well-written post. I really liked the learn by doing approach accompanied by flow diagrams. It's easy to get lost in the weeks with OAAuth terminology and this really kept good focus. I also looked at some of the author's other posts on things Protobufs and Tries and found them similarly enjoyable. I look forward to reading future posts and hope you post them here as well.
- bswamina 6y agoThanks for the encouragement ... started posting to Hacker News starting this year and will continue going forward
- hardwaresofton 6y agoFor those who are looking for an alternative and are OK with centralization of Auth which is somewhat different from the goals of OAuth, check out the CAS standard -- it's an alternative to SAML more so than OAuth. It's so simple I wrote (and abandoned) a golang library that implements v1[2]. I didn't need the proxy abilities in v2 (and doubt most orgs actually do) and I use JSON in some places before it was in the standard but it was very easy to implement and thus I can say it's easy to understand. I've meant to convert the project to Rust for a long time but at this point I'll probably never get to it. [0]: https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Spe... [1]: https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.htm... [2]: https://github.com/t3hmrman/casgo https://github.com/t3hmrman/casgo
- user5994461 6y agoI really wouldn't advise to use CAS in 2020. It's an historical curiosity that stopped being relevant some years ago. It's an old protocol to do single sign on within a company. It worked well and I've seen it used in large companies circa 2010, allowing to support sso in their internal web applications, for employees. CAS is irrelevant now. The world has standardized on OpenID Connect (and SAML as second choice). Anything that's on CAS was migrated or is pending migration to OIDC. As a developer you will have to deal with OIDC (and maybe SAML) for integrations with google auth, facebook auth, microsoft active directory. You really don't want to go for a dying ecosystem (CAS), that's a dead end for your career.
- amingilani 6y agoI really wish banks would read this.
- brujoand 6y agoThe one thing that really bugs me about the OAuth flow is what is described as step 3. When the application who wants to access data on your behalf is redirected to a login page where the user enters credentials and grants access. In many apps, these login redirects happen inside the app window, hiding the url. And even if the URL isn’t hidden, there’s suddenly a browser window inside my app and many unconscious “security checks” fail to load. I’d much rather have the OAuth provider send me an email or get a notification that can be actioned within the OAuth providers app so that I know I’m not giving my credentials to something that looks like the OAuth providers sign in page.
- qes 6y agoI never understood this either. So many apps pop up a window to enter my credentials to Google or Facebook or whatever in a manner that just screams don't put your password in here you have no idea who's hosting this form.
- ablekh 6y agoWould you think that, for an early-stage SaaS startup (enterprise B2B focus), the optimal strategy for implementing AuthN/AuthZ would be to use a managed service (e.g., Auth0) for MVP development and after that (perhaps, during pilots phase) migrate to an open source solution (e.g., Keycloak)?
- anderspitman 6y agoDo you need to provide access to third-party apps? If not you probably don't need oauth. Just use session cookies.
- ablekh 6y agoThank you for your comment. Yes, I'm planning to allow running third-party apps on the platform (the exact delivery options and relevant architectural details are still under consideration). My understanding is that using JWTs is the current best practice and much preferred way for authentication vs. the session-based approach. The platform that I plan to build should be both highly scalable and highly secure. I think that session cookies is not the right approach for these requirements, even if I would not need to allow running third-party apps. I'm curious about what people here think about this and hope that they will chime in. (I also would need SSO, external IdP integration, clustering, MFA, maybe passwordless authentication etc., hence my preference for managed services like Auth0. The idea is to focus on my core competencies and outsource important but non-core services to relevant solid providers, based on availability and feasibility, at least, for the near-to-mid term.)
- anderspitman 6y agoPersonally I don't think it's worth worrying about scaling like that until you actually need to. There are other reasons to choose JWTs, but I don't think scalability is a good one early on.
- ablekh 6y agoThank you for sharing your thoughts. I'm not worried about scaling and other aspects, but I do think about them. In my opinion, architectural decisions are the most important ones (across technological dimension) and fixing wrong or suboptimal architectural decisions is costly and/or difficult and sometimes outright not feasible.