4 ms·

Its baked into ASPNET Core, and its still a pain in the ass. Even though the middleware handles JWT validation, cookie storage, redirects etc (which are a big

Its baked into ASPNET Core, and its still a pain in the ass. Even though the middleware handles JWT validation, cookie storage, redirects etc (which are a big part of it) there are still a tonne of little details to OAuth that clients need to know enough to specify: - what grant flow are you using (code, hybrid, implicit, resource owner etc.. all are valid for different and overlapping scenarios, based on how secure you want to be and how much hassle you want your users to experience) - client id and secret management, and registering this with your server - refresh tokens: i.e. how do I prevent my user needing to log in every 15 minutes without making my jwt last an insecure amount of time. etc. etc. etc. I've built OAuth/OIDC into dozens of apps, and have deployed my own identity providers (not rolled my own, thank the gods, just used a framework for the server side) and its still the bane of my development existence.

zxcvbn4038 8y ago
That is another good point - generally you want to force a user to reauthenticate whenever they enter an elevated security context (account management, personal information, etc). With the OAUTH flows there doesn’t appear to be s way to do this. If I tried to send them through the login process again, they would just end up back at my callback address because their token was still valid.
- dwaite 8y ago
  Two ways to interpret your problem: 1. You want to perform a stronger form of authentication for users who are interacting with certain parts of your application In this case, you can proceed in two ways. One would be to use the OpenID Connect authentication context parameter and request the stronger form of auth directly. I personally dislike this approach because it bleeds business logic into all your clients, although it is popular in some government use cases (where authentication levels are part of the API contract). You can also have the applications represent the elevated security context as scopes (e.g. a moderation or admin scope). The business logic within the AS can interpret requests for these scopes as requiring stronger authentication 2. You want to reauthenticate the user when they go to an elevated security context. The AS should be responsible for your authentication policy, and deployments tend to go simpler if you don't split this responsibility with the application. The traditional way to do this would be similar to the scope rule above: scopes representing access to elevated contexts, and the AS recognizing it needs to enforce stricter authentication rules for this to work. For instance, you could have a rule that the user needs to reauthenticate every half hour, and make access tokens which have elevated privilege scopes have a limited lifetime to force retrieving a new token. A more modern way to do this might involve stepping back and looking holistically at why you are reauthenticating the user. This might be because you are worried that someone may have walked up to an unlocked machine and proceeded to try to access administrative features. For this, you might instead look at using EMM and machine policy to reduce that risk rather than impacting UX - such as reducing the time of the screen lock and eliminating the ability to use hot corners to keep the screen awake for users with administrative access. Your AS can then detect and rely on EMM compliance as a factor.

zxcvbn4038 8y ago

That is another good point - generally you want to force a user to reauthenticate whenever they enter an elevated security context (account management, personal information, etc). With the OAUTH flows there doesn’t appear to be s way to do this. If I tried to send them through the login process again, they would just end up back at my callback address because their token was still valid.

dwaite 8y ago
Two ways to interpret your problem: 1. You want to perform a stronger form of authentication for users who are interacting with certain parts of your application In this case, you can proceed in two ways. One would be to use the OpenID Connect authentication context parameter and request the stronger form of auth directly. I personally dislike this approach because it bleeds business logic into all your clients, although it is popular in some government use cases (where authentication levels are part of the API contract). You can also have the applications represent the elevated security context as scopes (e.g. a moderation or admin scope). The business logic within the AS can interpret requests for these scopes as requiring stronger authentication 2. You want to reauthenticate the user when they go to an elevated security context. The AS should be responsible for your authentication policy, and deployments tend to go simpler if you don't split this responsibility with the application. The traditional way to do this would be similar to the scope rule above: scopes representing access to elevated contexts, and the AS recognizing it needs to enforce stricter authentication rules for this to work. For instance, you could have a rule that the user needs to reauthenticate every half hour, and make access tokens which have elevated privilege scopes have a limited lifetime to force retrieving a new token. A more modern way to do this might involve stepping back and looking holistically at why you are reauthenticating the user. This might be because you are worried that someone may have walked up to an unlocked machine and proceeded to try to access administrative features. For this, you might instead look at using EMM and machine policy to reduce that risk rather than impacting UX - such as reducing the time of the screen lock and eliminating the ability to use hot corners to keep the screen awake for users with administrative access. Your AS can then detect and rely on EMM compliance as a factor.