Understanding OAuth2 and OpenID Connect • Hacker News Board

Re: Understanding OAuth2 and OpenID Connect

#61

Post by mooreds » Tue, Sep 08, 2020, 2:24 AM UTC

different_sort wrote: post #60

mooreds wrote: post #53

Earlier quoted context omitted.

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 worr…

> This is not so different than using a session cookie that is not marked as 'httponly'.

The difference is a session cookie is tied to one server, but an access token could be used with many different APIs or other services. That said, an access token may expire more quickly, so the devil is definitely in the details.

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

That makes sense, for sure. You could definitely require MFA to get an access token and have it be short lived. At that point it gets to a question of UX and how much impact you want on your users, but I'm not familiar with all the requirements you have.

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

Please do! Happy to respond here or if you want to check out the FusionAuth forum (which I monitor), you can find it on the the website under the resources tab.

Re: Understanding OAuth2 and OpenID Connect

#62

Post by the_af » Tue, Sep 08, 2020, 3:05 PM UTC

bswamina wrote: post #58

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

Thanks! Much better now.

Re: Understanding OAuth2 and OpenID Connect

#63

Post by anderspitman » Thu, Sep 10, 2020, 5:32 PM UTC

ablekh wrote: post #59

anderspitman wrote: post #55

Earlier quoted context omitted.

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 thin…

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

Re: Understanding OAuth2 and OpenID Connect

#64

Post by ablekh » Thu, Sep 10, 2020, 8:00 PM UTC

anderspitman wrote: post #63

ablekh wrote: post #59

Earlier quoted context omitted.

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 thin…

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

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

Re: Understanding OAuth2 and OpenID Connect

#65

Post by anderspitman » Fri, Sep 11, 2020, 5:34 PM UTC

ablekh wrote: post #64

anderspitman wrote: post #63

Earlier quoted context omitted.

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

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

True, but you can further break architectural decisions down into those that are easy to change and those that aren't. If something is easy to change you may as well implement the simple version first.