For step 3 of the OIDC Playground, you can leave this section as-is or modify for customization of your testing.
Configurable Parameters:
Recommended value: code
OAuth supports several different authorization grant types. As a best practice, Hosted Login supports the Authorization code grant. With this grant type, the authorization endpoint returns a special one-time code back to your site or application. This code can then be exchanged for an access token, a refresh token, and an identity token. For more information, see An introduction to OAuth 2.0 and OpenID Connect.
The Authorization code grant must be specified in the OpenID Connect request by setting the response_type
parameter to code.
Although other response types are supported for certain use cases and compatibility needs, only the code type should be used with this Getting Started Guide and the OIDC Playground.
Other supported response types:
Must include: openid
The scope
parameter is used to specify what user information you’d like to retrieve immediately when a user logs in. You can request more than one scope in this parameter.
Possible scope values:
Would you like to request user data that is not contained within the above scopes? You can use custom claims for this - see the Additional Claims section below.
For more information on scopes, see Scopes and claims.
Overrides the default behavior when a user takes an action on your site or app that requires authentication. Example user actions are loading a page or clicking a button.
If this parameter is omitted, the default behavior will be preserved: Hosted Login will look for an existing valid session and, if found, the user is automatically authenticated and can seamlessly continue. If a valid session is NOT found, the user will be prompted to sign in.
Possible prompt values:
Scenario |
---|
You want to provide a hidden Single Sign-On (SSO) experience to your end users when they navigate between your sites. In such case, you can call Hosted Login with prompt=none to secretly check for a valid Hosted Login session when they navigate to one of your sites. If a valid session is found, you can automatically log them in. If a valid session is NOT found, you can do nothing and allow them to sign in per usual if they so choose. |
Scenario |
---|
Let’s say user A logs into your site at a shared computer and forgets to log out, then user B hops on the same computer. If user B is malicious, they could take actions in user A’s account with the existing session. However, if certain sensitive actions call Hosted Login with prompt=login , user B will be unable to continue those actions without proving ownership of the account. |
Scenario |
---|
You have a promotion that only applies to new customers. You provide a “Sign up to get 20% off my first purchase” button. Clicking the button calls Hosted Login with prompt=create to present the registration screen to the user, and does not give the option for an existing user to sign in. |
Can be used to override the default display behavior of Hosted Login with a popup.
If this parameter is omitted, the default behavior will be preserved: The Hosted Login screens will be displayed as full pages within the same browser window as your site or app.
Possible display values:
display=page
to get the exact same result: The Hosted Login screens will be displayed as full pages within the same browser window as your site or app.NOTE! The rendering of the popup is NOT automatically done for you by Hosted Login. In this case the OIDC Playground reads the display parameter and renders the Hosted Login screens in a popup if specified. If you want the same functionality in your own site or app, you will need to add code to your site or app to do the same.
Overrides the default language used in Hosted Login screens. This value must match (or at least partially match) a locale defined in your Registration Flow configuration.
If this parameter is omitted, Hosted Login will use the browser’s language setting. If the browser’s language setting does not match a locale defined in your Registration Flow configuration, then the default locale will be used: en-US
(American English)
If you’d like to present the Hosted Login screens to the user in a different language, you must follow a 2-step configuration process:
ui_locales
parameter in your call(s) to Hosted Login with the new locale as the value. Example: ui_locales=fr-CA
(Canadian French)
ui_locales
parameter and Hosted Login will use the browser’s language setting.For more information on the ui_locales
parameter, see UI Locales.
Overrides the default max age (specified in seconds).
Specifying the max age in your call to Hosted Login is your way of saying “the user is only allowed to take this action if they’ve signed in within the last X amount of time.” If the max age has been reached, a user attempting the action will be prompted to sign in again in order to continue.
If this parameter is omitted, the user will be prompted to sign in if 30 days has passed since their last login.
The actual value being used by default is 2592000
, which is 30 days specified in seconds.
Good to know:
authorization.rules.auth_ttl
setting in Global Settingsauthorization.rules.auth_ttl
setting in Settings for the applicable property or propertiesmax_age
parameterFor more information on the authorization.rules.auth_ttl
setting, see Authorization rules.
Scenario |
---|
Let’s say user A logs into your site at a shared computer and forgets to log out, then user B hops on the same computer. If user B is malicious, they could take actions in user A’s account with the existing session. However, if certain sensitive actions call Hosted Login with max_age=1800 (30 minutes), the window of opportunity for user B to continue with those actions is greatly decreased. Note: You can alternatively use prompt=login for sensitive actions, which behaves the same as max_age=0 . |
Optionally used for added security.
A “nonce” in this context is a random, case-sensitive string that you pass to Hosted Login, and in turn Hosted Login will pass back an ID Token containing the same string. This allows for verification of the returned ID Token and prevents replay attacks.
For more information, see Nonce.
Click NEXT.
For step 4 of the OIDC Playground, you can leave this section as-is or modify for customization of your testing.
Standard claims can optionally be used if you’d like to request individual fields of standard data instead of (or in addition to) asking for groups of standard data via the scope parameter.
Custom claims can optionally be used to request user data other than the standard fields. For example, if you add a custom attribute to the schema to store the user’s favorite color, you can use Custom Claims to request access to that additional data.
For more information on claims, see Scopes and claims.
Click FINISH.