Requiring re-authentication before permitting sensitive actions on client side

You’re trying to figure out how to force an already signed-in user to re-enter their password before allowing them to access a sensitive area of your service? This is for you.

Your service isn’t supposed to have access to the User’s credentials, so adding a password query on your website is out of the question. The solution is to have the ID service re-authenticate the User before allowing them to perform sensitive actions.

Determining authentication age

Your service can use the iat claim of the ID token to find when it was issued.

iat: Time at which the JWT was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.

ID Token

Re-authentication

When your web site determines that an user should re-authenticate, you should show them a notification of this before directing to authentication so they are not surprised by this.

You will use the same authentication URL as you use during normal authentication, but with some differences in parameters to force the user to authenticate with the same account.

Suggested parameters

Request parameter	Value	Effect
login_hint	Username or email address which may be automatically inserted into the “login name” field.	User doesn’t have to re-enter the username unnecessarily.
prompt	login	Forces the user to re-authenticate regardless of any existing “remember me” cookies or sessions.
claims	{ "userinfo": { "sub": { "value": "123456789abcdefgh" } } }	The ID server will prevent authentication unless it is done with an user account with the given UserID (sub = subject = userid).
state	Information of your choice, will be passed to the authentication callback.	You can direct the user to the correct page by reading the state value after successful re-authentication.

After a successful re-authentication, your service should still verify that the user account is correct, or alternatively just service the other account.