Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding OAuth2 and OpenID Connect

polarsparc.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Understanding OAuth2 and OpenID Connect

#51

Post by user5994461 »

hardwaresofton wrote: post #46

For 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 s…

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

Re: Understanding OAuth2 and OpenID Connect

#52

Post by bswamina »

bogomipz wrote: post #45

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

Thanks for the encouragement ... started posting to Hacker News starting this year and will continue going forward

Re: Understanding OAuth2 and OpenID Connect

#53

Post by mooreds »

different_sort wrote: post #47
mooreds wrote: post #36

This 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 allo…

Storing tokens in cookies would be against the spec wouldn’t it? I’m not putting rfc6749 on some sort of pedestal, but it clearly states that the tokens are in the response body and not set in cookies. Do you have any examples of Authorization servers in the wild doing this or front end SDKs that work with that? I’m very curious, I’m doing an SPA security research project at work and I’m very interested in these stor…

Hiya,

Sorry, I was wrong. According to the spec you definitely have to send the access token back in the response body[0].

However, a client can store them as cookies (or, as you mention, other places, such as a service worker[1]). This is useful if the client is a single page application (SPA), which may need to present the access token to other resource servers.

RFC 6750 has something to say about how to store the bearer token [2]:

> Don't store bearer tokens in cookies: Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.

So, I apologize. The authorization server wouldn't send the access token as a cookie. Instead, there'd be a server side proxy which would request the token and then send it down as a secure cookie. Again, best practice would be to keep the access token on the server side proxy and just send a session id down to the client, but that sometimes doesn't work. Here is a diagram illustrating that path (with the 'store' entity acting as the proxy mentioned above)[3].

0: https://tools.ietf.org/html/rfc6749#section-5.1

1: https://gitlab.com/jimdigriz/oauth2-worker

2: https://tools.ietf.org/html/rfc6750#page-13

3: https://fusionauth.io/learn/expert-advice/authentication/web...

Re: Understanding OAuth2 and OpenID Connect

#54

Post by WGH_ »

patmorgan23 wrote: post #5
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.

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.

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

Re: Understanding OAuth2 and OpenID Connect

#55

Post by anderspitman »

ablekh wrote: post #50

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

Do you need to provide access to third-party apps? If not you probably don't need oauth. Just use session cookies.

Re: Understanding OAuth2 and OpenID Connect

#56

Post by anderspitman »

sjroot wrote: post #7
the_af wrote: 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…

Are any of the big players (ie FAANG) actually using PKCE yet?

Re: Understanding OAuth2 and OpenID Connect

#57

Post by qes »

brujoand wrote: post #49

The 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 “sec…

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

Re: Understanding OAuth2 and OpenID Connect

#58

Post by bswamina »

the_af wrote: 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.

Thanks for the feedback. Had made changes and added a little more

Re: Understanding OAuth2 and OpenID Connect

#59

Post by ablekh »

anderspitman wrote: post #55
ablekh wrote: post #50

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

Do you need to provide access to third-party apps? If not you probably don't need oauth. Just use session cookies.

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

Re: Understanding OAuth2 and OpenID Connect

#60

Post by different_sort »

mooreds wrote: post #53
different_sort wrote: post #47

Earlier quoted context omitted.

Storing tokens in cookies would be against the spec wouldn’t it? I’m not putting rfc6749 on some sort of pedestal, but it clearly states that the tokens are in the response body and not set in cookies. Do you have any examples of Authorization servers in the wild doing this or front end SDKs that work with that? I’m very curious, I’m doing an SPA security research project at work and I’m very interested in these stor…

Hiya, Sorry, I was wrong. According to the spec you definitely have to send the access token back in the response body[0]. However, a client can store them as cookies (or, as you mention, other places, such as a service worker[1]). This is useful if the client is a single page application (SPA), which may need to present the access token to other resource servers. RFC 6750 has something to say about how to store the…

Thank you for your replies and insight, it's really appreciated.

The way I see it with SPA and tokens in JS accessible space is that you're exposing your users to the possibility of token theft and user impersonation if someone is able pull off an XSS. This is not so different than using a session cookie that is not marked as 'httponly'. What's old is new again :)

I have also heard the argument that we shouldn't worry about token theft, because it's already too late if you're XSS'd, but I don't buy into that rhetoric(not saying XSS isn't incredibly bad).

Unfortunately I work in financial services, so we can't just skate by and assume that we're so uninteresting that an adversary with advanced capabilities wouldn't look to exploit our external or internal users somehow.

One another thing we're looking into is access tokens, like having the user re-authenticate or use a stronger factor(or multiple) to get the AS to grant them a very short lived, non-refreshable token to do their sensitive operation.

I'm going to check out the fusionauth blog for a bit more inspiration, if you're interested in continuing this discussion I would be interested in carrying it on.

Post reply on HN