Re-Authentication

Introduction

In certain situations it is necessary for a user to authenticate again for a certain action. For example, this may be required for sensitive actions within an application to increase security. This article describes how this can be done.

Authentication Request without action

By sending an authentication request, the user can be forced to log in again:

https://server.example.com/connect/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &prompt=login
    &login_hint=c1s:89
    &max_age=60
    &redirect_uri=callbackurl
    &acr_values=coreone:authentication:loa:user:max

From the call shown, there are a few important parameters that can control the behavior:

Parameter	Value	Impact

Parameter	Value	Impact
`prompt`	login	By setting the value to "login" a re-authentication is initiated
`login_hint`	c1s:89	If this value is set, reauthentication is initiated for the specified user. If the value is read empty, another user can theoretically log in. Depending on the situation, this may or may not be desired.
`max_age`	60	How long ago the user last logged in without having to log in again. For example, if he last logged in 30 seconds ago, he does not have to log in again. In certain situations this is desired. If he should have to log in in any case, the parameter can be omitted or set to 0.
`redirect_uri`	callbackurl	The URL which should be called in case of successful reauthentication.
`acr_values`	coreone:authentication:loa:user:max	The desired level of authentication for the reauthentication. If none is supplied, the LOA of the client is used. For maximum security, the maximum LOA set up for the user can be enforced here using coreone:authentication:loa:user:max, for example.
`ui_locals`	de	The desired UI language
`reauthentication_action`		A variety of actions can be initiated from within the re authentication request. `ActivateMethodAction` `AddExternalAccountAction` `ChangeSecretAction` `ClearPreferredLogonMethodAction` `CreateCommunicationMethodAction` `DeactivateAccountAction` `DeactivateAllMethodsAction` `DeactivateMethodAction` `DeactivateUserClientLogonMethodAction` `DeleteAccountAction` `DeleteCommunicationMethodAction` `IncreaseQualityOfRegistrationAction` `RemoveExternalAccount` `ResetClientCommunicationDataMethodAction` `ResetClientLogonDataMethodAction` `ResetDeactivatedUserClientLogonMethodAction` `SetDefaultCommunicationMethod` `SetPreferredMfaLogonMethodAction` `UpdateClientCommunicationDataMethodAction` `UpdateClientLogonDataMethodAction` `UpdateCommunicationMethodAction`
`redirect_on_terminate`	URL	If the users cancels the re authentication, the user will be sent to this address

Authentication Request with action

Many IdP related actions such as a password change, changing of an e-mail address and so on might be initiated from other applications. Those applications can leverage the reauthentication_action property to initiate the documented processes. Below is an example of how to initiate a password change (line 11 and line 12):

https://server.example.com/connect/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &prompt=login
    &login_hint=c1s:89
    &max_age=60
    &redirect_uri=callbackurl
    &acr_values=coreone:authentication:loa:user:max
    &reauthentication_action=ChangeSecretAction
    &action=changesecret:password

Validation

It is important that the token is rechecked on the application side in the callback action. Here the "iat" value (issued at) must be validated to ensure that the time is within the desired period.