Angular-auth-oidc-client: Support id_token_hint request parameter Using prompt=none with user hint through id_token_hint

Created on 17 Jun 2017  路  7Comments  路  Source: damienbod/angular-auth-oidc-client

enhancement

Most helpful comment

I needed to add acr_values to the authorizeUrl. I ended up overwriting the createAuthorizeUrl method on the service to invoke the original and then append the additional properties as needed.

Total hack, but it worked. In favor of what @r4hulp suggested.

const service = (this.oidcSecurityService as any);
const originalCreateAuthorizeUrl = service.createAuthorizeUrl;
service.createAuthorizeUrl = (nonce: string, state: string) => {
      let url = originalCreateAuthorizeUrl.call(this.oidcSecurityService, nonce, state);
      url += '&acr_values=' + encodeURI('email:[email protected]');
      return url;
    }

All 7 comments

specs:

prompt
OPTIONAL. Space-delimited, case-sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are:

        none
            The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required. This can be used as a method to check for existing authentication and/or consent. 
        login
            The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required. 
        consent
            The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required. 
        select_account
            The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically account_selection_required. 

    The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request. If this parameter contains none with any other value, an error is returned. 
max_age
    OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. When max_age is used, the ID Token returned MUST include an auth_time Claim Value. 
ui_locales
    OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider. 
claims_locales
    OPTIONAL. End-User's preferred languages and scripts for Claims being returned, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider. 
id_token_hint
    OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value. 
login_hint
    OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion. 
acr_values
    OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this authentication request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2.2. The acr Claim is requested as a Voluntary Claim by this parameter. 
registration
    OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 3.2.1.

I was thinking around something that will allow this library to add additional required parameters on the fly.

e.g. The way Azure AD has implemented implicit flow is little different than oid specs. We can not keep adding all the parameters for all the providers. That will make this library a mess.

Instead, how about introducing something like additional parameters type like dictionary. We can build the URL depending upon values in dictionary.

I needed to add acr_values to the authorizeUrl. I ended up overwriting the createAuthorizeUrl method on the service to invoke the original and then append the additional properties as needed.

Total hack, but it worked. In favor of what @r4hulp suggested.

const service = (this.oidcSecurityService as any);
const originalCreateAuthorizeUrl = service.createAuthorizeUrl;
service.createAuthorizeUrl = (nonce: string, state: string) => {
      let url = originalCreateAuthorizeUrl.call(this.oidcSecurityService, nonce, state);
      url += '&acr_values=' + encodeURI('email:[email protected]');
      return url;
    }

I'll implement this next, this has been open a while. Good that you could implement it.

custom parameters can now be used for this since version 1.3.4

supported with the custom parameters function

Was this page helpful?
0 / 5 - 0 ratings

Related issues

toddtsic picture toddtsic  路  4Comments

yelhouti picture yelhouti  路  4Comments

revok picture revok  路  4Comments

nizarkhsib picture nizarkhsib  路  4Comments

haidelber picture haidelber  路  3Comments