4 ms·

That is another good point - generally you want to force a user to reauthenticate whenever they enter an elevated security context (account management, personal

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.

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.