Overview[1]#

Login_hint_token is used to pass a user hint into the authentication process at the OpenID Connect Provider.

Login_hint_token is opaque to the client by design.

There are several ways for a client to obtain a Login_hint_token.

The MODRNA discovery service MODRNA.Discovery creates a Login_hint_token if the user has entered their MSISDN in the course of the Mobile Network Operator discovery process. In the case of a Login_hint_token produced by the MODRNA Discovery Service it is an encrypted JSON Web Token (JWT RFC 7519) that contains a Login_hint_token for the OpenID Connect Provider. The Login_hint_token SHALL be used by the client as login hint with OpenID Connect Provider identified by the MODRNA discovery service MODRNA.Discovery. In this case, the Login_hint_token is supposed to be a signed (JWS) and encrypted [JWE]) JWT.

The Authorization Server MAY produce Login_hint_token in other formats for use in Account Chooser or other discovery profiles, as long as they are confidentiality protected from the client.

The Login_hint_token produced by the MODRNA discovery service MODRNA.Discovery has the following elements:

• iss - REQUIRED. The party creating the Login_hint_token. This value MUST be used by the Identity Provider (IDP) receiving the token to obtain the JWK RFC 7517 file required to validate the tokens's signature (see Section 6.1).
• aud - REQUIRED. The party to receive the token, typically the users OpenID Connect Provider. The value MUST be the issuer URI of the OpenID Connect Provider as exposed in the Identity Provider (IDP)'s openid-configuration meta-data.
• iat - REQUIRED. When the token was issued.
• MSISDN - REQUIRED. The Subscriber identifier formated according to ITU-T recommendation E.164

  {
   "iss": "https://discovery-provider.com",
   "aud": "https://babytel.com",
   "iat": 1311280970,
   "MSISDN": "+1999550123"
  }

Login_hint_token encryption and signing#

In the first step, the openid-configuration for the Identity Provider (IDP) is retrieved by performing discovery Per Section 4 of OpenID.Discovery using the issuer string for the users Identity Provider (IDP) as the input. In the next step, the value of the "jwks_uri" claim Per Section 3 of OpenID.Discovery is used to retrieve the OpenID Connect Provider's JWK RFC 7517. A public key in the JWK with a use paramater of "enc" per Section 4.2 of JWK RFC 7517 is used as the encryption key. The Login_hint_token is then encrypted as a JWE using that key.

The login_hint token MUST be signed using the private key of the Discovery Service.

It is best practice to sign then encrypt tokens, as signatures over encrypted information may leak information in the envelope, and may not be considered legally valid.

For an example of a nested JWT that is signed and then encrypted see Appendix 2 of JWT RFC 7519.

NOTE: The login_hint_token is opaque to the client by design. The Authorization Server may produce Login_hint_token in other formats for use in Account Chooser or other discovery profiles, as long as they are confidentiality protected from the client.

More Information#

• OpenID Connect MODRNA Authentication Profile 1.0

• [#1] - openid-connect-modrna-authentication-1_0 - based on information obtained 2017-03-07-