OpenID Connect APIs

In this article:

/{customerId}/login/authorize


Requests an authorization code from the authorization endpoint. 

The /{customer_id}/login/authorize endpoint is used to request an authorization code from the authorization endpoint. If this call succeeds, the client is given an authorization code; that code can then be presented to the token endpoint and exchanged for an access token, refresh token, and identity token.

If an authorization request is accepted, the user is presented with the sign-in screen and is asked to log on to the site or app. If authentication succeeds, the user will be fully logged on to the site, will be issued an access token, a refresh token, and an identity token, and then be redirected to the URL specified in the authorization request.

Note. That’s a slightly-abridged version of the authorization and authentication process. For a more-detailed version, see the article Authorization Code + PKCE.

A typical authorization request looks something like this: 

https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/login/authorize
   ?client_id=64430515-01ea-4f5d-82e4-c36161af009
   &redirect_uri=https://oidc-playground.akamai.com/redirect_uri
  &scope=openid email phone
   &code_challenge=y63Qmobx6ZCSYCZqPNzQ6Qx1rGK0reaxgbb5WSAQR0o
   &code_challenge_method=S256
   &response_type=code
   &state=tbXZO4Fkxy90JvJx0s2sbt-FsK2yNK0tqYrX4YvPjB4


Note. A few carriage returns and blank spaces were added to the preceding request in order to make it easier to read. A real authorization request looks more like this:

https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/login/authorize?&client_id=64430515-01ea-4f5d-82e4-c36161af0093&redirect_uri=https%3A%2F%2Foidc-playground.akamai.com%2Fredirect_uri&code_challenge= y63Qmobx6ZCSYCZqPNzQ6Qx1rGK0reaxgbb5WSAQR0o&code_challenge_method=S256&response_type=code &scope=openid%20email%20phone&state=tbXZO4Fkxy90JvJx0s2sbt-FsK2yNK0tqYrX4YvPjB4

The parameters used in the preceding authorization request, as well as additional parameters than can also be used in a request, are summarized in the table below:

Request Parameters

The query parameters for the /{customer_id}/login/authorize endpoint include the following:

Parameter

Required

Description

client_id

Yes

Unique identifier of the OIDC login client used to make the authorization request. For example:

cliient_id=22c9604-7b27-464f-bff5-83ba229323af

response_type 

Yes

Specifies the type of response expected from the authorization server; at this point in time the Identity Cloud only supports the code response type. Note that this parameter is required even though there’s only one supported response type:

response_type=code

The code response indicates that the client expects to get an authorization code back following a successful authentication. In turn, the client exchanges that code for a set of tokens.

scope

Yes

Specifies the OpenID Connect scopes to be accessible from the userinfo endpoint following a successful authentication and login. Note that you must include the scope parameter and, at a minimum, request the openid scope; this tells the authorization server that you want to authenticate by using OpenID Connect.

Other scopes supported by the Identity Cloud are detailed in the article OpenID Connect Scopes and Claims. You can request multiple scopes by separating each scope using a blank space:

scope=openid email profile

You can include any (or all) the supported scopes in your authentication request. However, that doesn’t mean that you’ll get back all of those scopes. Instead, the scopes made accessible from the userinfo endpoint depend on the value of the allowedScopes property found in the token policy applied during a user login. 

For example, suppose the allowedScopes property only specifies the openid and email scopes. In that case you can only get back those two scopes; any other scopes mentioned in your authorization request (such as profile or address) are ignored and are not returned.

redirect_uri

Yes

Specifies the URL of the page the user is redirected to following a successful authentication and login. For example:

redirect_uri=https://identitydocs.akamai.com/redirect

Note that the specified URL must be exactly match one of the URLs listed in the OIDC login client’s redirectURIs property. If the URL isn’t included in the redirectURIs property then the authorization request fails with an Invalid client error and the user will not be authenticated.

code_challenge

Yes (with PKCE)

Hashed and encoded value generated by the client. This value should be verified before the client is allowed to exchange an authorization code for a set of tokens.

For example:

code_challenge= RTg4QjMyRUJCNzdBRTQ1MkM2NTAzRTVDOEQ5OTg
3QjIwMjVBNTcxQTU5RTJFNDYwMzJBQjYxRkM4NjQ0QzdBNw

code_challenge_method

Yes (with PKCE)

Hashing algorithm used to generate the value of the code_challenge parameter. For Hosted Login, this will always be S256:

code_challenge_method=S256

state

No (but recommended) 

A random string that helps guard against cross-site request forgery (CSRF). For example, suppose your authentication includes the following state parameter and parameter value: 

state=GA-ISU_6CwFn0tQTFiYD_-Gvy39Nb6iTdugdGIzTUng

After a successful authentication, you’ll be redirected to the URL specified by the redirect_uri parameter. If you were redirected by the authorization server then the state parameter and value will be included in the URI:

https://identitydocs.akamai.com/redirect_uri?code=AH6S2WG_XchALC-p&state=GA-ISU_6CwFn0tQTFiYD_-Gvy39Nb6iTdugdGIzTUng

If the state parameter in the redirect URI doesn’t match your original parameter value then you might be the victim of CSFR attack (defined as an attack in which malware tries to trick you into carrying out some sort of action you never intended to carry out). In that case, you should restart the authentication process.

prompt

No

Specifies which screen (if any) is displayed when a user makes an authorization request. Allowed values are:

  • none. When prompt is set to none, Hosted Login first checks to see if the client has a valid session. If a valid session is found the user doesn't need to authenticate; instead, he or she is automatically logged in using the existing session. If a valid session can't be found a "No authenticated session found" error is generated and the user is not given the option of logging in.

    If you set the prompt parameter to none, it's recommended that you write code that: 1) looks for the "No authenticated session found" error ; and, 2) displays the sign-in screen. (If you don't, a user without an existing session would never be able to log in.) You might consider creating a cookie indicating that the user has been denied access because they didin't have a valid session. If you do that then, the next time user accesses your site , you'll know to employ an authorization request where the prompt is set to login (i.e., a request where the sign-in screen is always displayed).
     
  • login. The sign-in screen is always displayed first, even if a valid session is found. This ensures that users log in each time they access the site.
     
  • create. The traditional registration screen (used for creating new account) is always displayed first. Note, however, that the Sign In link isn’t found on the traditional registration screen. That means that setting the prompt to create represents a dead-end for existing users: they don’t need to create account, but they can’t log on using their existing account.

If this parameter isn't included then Hosted Login first checks to see if the client has a valid session. If a valid session exists the user doesn't need to authenticate; instead, he or she is automatically logged in using the existing session. If a valid session can't be found then the sign-in screen is displayed and the user can log in. 

For example:

prompt=login

max_age

No

Specifies the amount of time, in seconds, that can elapse before a user is required to reauthenticate. For example, suppose the max_age parameter is set to 3600 seconds (one hour). A user logs on, leaves the website, then returns 30 minutes later. Because the max_age limit of 1 hour has not been reached, the user will automatically be authenticated and resume their previous session.

Now, suppose a second user logs on, leaves the website, then comes back 2 hours later. because the max_age value has been exceeded, this user will be forced to reauthenticate.

Note that the max_age parameter applies only to logins. Suppose a third user logs on and stays on the site for 2 hours. That user will not be forced to reauthenticate halfway through their session. As noted, max_age only applies to logins.

ui_locales

No

Specifies the language/locale used when displaying Hosted Login login, registration, and user profile screens. Language preferences are passed as a space-delimited set of RFC 5646 language codes. For example:

ui_locales= fr-FR es-ES

In the preceding example, Hosted Login first tries to render screens by using French (fr-FR); if that fails, Hosted Login tries to render the screens by using Spanish (es-ES). If that fails, then Hosted Login defaults to displaying all screens in English.

Why would an attempt to render screens fail? This is almost always because you specified a language/locale that can’t be found in your flow: you can specify any language or locale that you want, but to actually display screens using that language/locale requires you to have the locale (and the accompanying translations) in your flow. See this article for more information.


login_hint

string

Provides a way to prepopulate the email address field on the Hosted Login sign-in screen. In your authorization request, include the login_hint parameter followed by the email address of the user who needs to be authenticated. For example:

https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/login/authorize?
    &client_id=a123ef65-83dc-4094-a09a-76e1bec424e7
    &redirect_uri=https%3A%2F%2Fwacky-harmonious-bike.dev.or.janrain.com%2Fredirect_uri
    &code_challenge=MJm7VEGLvMtD4Mi1SGUc2QPRPVKqyaoEbBTxYKC4UJk
    &code_challenge_method=S25
    &response_type=code
    &scope=openid
    &state=5TK5-3LXryr8EIxn6kV4mgqEa3KqRA4-HwHJbyzlgU0
    &login_hint=gmstemp@hotmail.com

When you submit your authorization request, the email address will be included on the sign-in screen:

Note that Hosted Login cannot determine the email address to be included in the authorization request. Instead, you will need to use an alternate approach to determine the email address (for example, getting the email address when the user logs on to the computer) and then take the steps needed to add that address to the authorization request.

claims

No

Specifies the claims (i.e., user profile attributes) to be included in the identity token or to be made accessible from the userinfo endpoint (or both). These claims can either be standard OpenID Connect claims (see OpenID Connect Scopes and Claims for more information) or custom claims created by your organization and defined in your login policies.

For example, this syntax makes the birthdate claim accessible from the userinfo endpoint:

&claims={"userinfo":{"birthdate":null}}

Meanwhile, this syntax adds a custom claim named organization to the identity token:

&claims={"id_token":{"organization":null}}

And this syntax makes the organization claim accessible from the userinfo endpoint and adds that same claim to the identity token:

&claims={"userinfo":{"organization":null}, "id_token":{"organization":null}} 

display

No

Specifies where (and how) the sign-in screen is displayed. Allowed values are:

  • page (the default value)., When you submit your authorization request, you’ll be redirected to a separate page that contains the sign-in screen (and nothing but the sign-in screen). After you’ve successfully logged on you'll be redirected to the page specified in the redirectURIs property of your OIDC client.
     
  • popup. When you submit your authorization request you are not redirected to a standalone login page. Instead, the login page appears in a pop-up window, no redirection required. After you’ve successfully logged on then you’ll be redirected to the page specified in the redirectURIs property of your OIDC client.

For example:

display=page

nonce

No, but recommended


Helps ensure that the identity token you receive is the same identity token that you requested (in other words, you got back a token sent in direct response to your authentication request).

To use the nonce parameter, simply enter a random string in the Nonce field and then make your authentication request, When you decode the returned identity token, you should see a nonce property. The value in the identity token should be the same as the value included in your authentication request.

Authentication

No authentication is required to call the /{customer_id}/login/authorize endpoint.

Sample Request 1: Authorization Code for Web Apps Flow (curl)

The following command uses the Authorization Code flow to request an authorization code from the endpoint https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/authorize:


https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/authorize?client_id=21d832df-e92e-4e32-80df-8726d47992fa&client_secret-ewt546srbs73&redirect_uri=https://documentation.akamai.com/debug&scope=openid&response_type=code&state=dgwt5dbcxja
 

Sample Request 2: Authorization Code + PKCE Flow (curl)

The following command uses the Authorization Code + PKCE flow to request an authorization code from the endpoint https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/authorize. To use PKCE, the code_challenge and code_challenge_method parameters were added to the previous authorization request.


https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/authorize?client_id=21d832df-e92e-4e32-80df-8726d47992fa&redirect_uri=https://documentation.akamai.com/debug&scope=openid&response_type=code&state=dgwt5dbcxja&code_challenge=RTg4QjMyRUJCNzdBRTQ1MkM2NTAzRTVDOEQ5OTg 3QjIwMjVBNTcxQTU5RTJFNDYwMzJBQjYxRkM4Nj Q0QzdBNw&code_challenge_method=S256
   

Responses

200 OK

If your call to this endpoint succeeds, you'll get back a response similar to the following. In this sample response, the authorization code has been highlighted in red:

https://v1.api.us.janrain.com/00000000-0000-3000-8000-000000000000/login/code?state=security_token%3bd5262737237ef4a %url%https://hosted-login.akamai.com/callback&code=4/JR27W91a-ofgCe9ur2m6bTghy77

Note that you will get the same response back regardless of whether you are using the Authorization Code flow or the Authorization Code + PKCE flow. When using the Authorization Code + PKCE flow, no information about the code challenge or code challenge method are included in the response.



/{customerId}/login/token

Back to top

Issues access, refresh, and identity tokens based on the requested grant type. 

Authentication

The authentication method used when calling this endpoint varies depending on the type of grant you are requesting:

  • authorization_code using a public client (PKCE). Authentication is not required when using a public client. However, you must include the code_verifier parameter when making a call from a public client.
  • authorization_code using a confidential client. Use Basic authentication, specifying the client ID of a confidential client as your username and the client secret of that same OIDC client as your password.
  • refresh_token. Authentication is not required.
  • client_credentials. Use Basic authentication, specifying the client ID of a configuration client as your username and the client secret of that same OIDC client as your password.

Methods

This endpoint supports the following methods:

  • POST

POST

Description

Issues access tokens and refresh tokens based on the requested grant type:

  • If the grant_type is set to authorization_code, an authorization code is exchanged for an access token, a refresh token, and an identity token.
  • If the grant_type is set to refresh_token, a refresh token is exchanged for a new access token.
  • If the grant_type is set to client_credentials, an access token is issued for the client based on its associated token policy.


Path Parameters

The path parameters that must be included in the request are listed in the following table:

NameTypeRequiredDescription

{customer_id}

string

Yes

Unique identifier of the customer requesting a token.


Body Parameters

The xxx-www-urlencoded body parameters for the /{customer_id}/login/tokens endpoint include the following:

NameTypeDescription

grant_type

string

Specifies the type of authorization grant being requested. Allowed values are:

  • authorization_code. Indicates that you want to exchange an authorization code for an access token, a refresh token, and an identity token.
  • refresh_token. Indicates that you want to exchange a refresh token for a new access token.
  • client_credentials. Requests an access token to be issued based on the client’s token policy.

code

string

The authorization code being exchanged. This parameter is required when using the following grant types:

  • authorization_code

refresh_token


The refresh token being exchanged. This parameter is required when using the following grant types:

  • refresh_token

code_verifier


Required if you are using PKCE (Proof Key for Code Exchange) and your original authorization request includes the code_challenge parameter. The code_verifier value must be the same value used to generate the initial code challenge. This parameter is required when using the following grant types:

  • authorization_code (PKCE requests-only)

redirect_uri


URL of the page the user will be redirected to following the token exchange. This parameter is required when using the following grant types:

  • authorization_code

scope


The value specified must match the scopes requested in the token policy associated with the OIDC configuration client. This parameter is required when using the following grant types:

  • client_credentials

client_id


ID of the OIDC client that made the initial authorization request. This parameter is required when using the following grant types:

  • authorization_code
  • refresh_token

client_secret

string

Secret associated with the OIDC login client used to make the authorization request. The need to include the client secret in the authorization request is the primary reason why the Authorization Code for Web Apps grant should not be used with devices (such as cell phones) that run on a non-TLS network.

code_challenge

string

Hashed and encoded value generated by the client. This value should be verified before the client is allowed to exchange an authorization code for a set of tokens.

For example:

code_challenge= RTg4QjMyRUJCNzdBRTQ1MkM2NTAzRTVDOEQ5OTg
3QjIwMjVBNTcxQTU5RTJFNDYwMzJBQjYxRkM4NjQ0QzdBNw

This parameter is used only with PKCE.

code_challenge_method

string

Hashing algorithm used to generate the value of the code_challenge parameter. For Hosted Login, this will always be S256:

code_challenge_method=S256

This parameter is used only with PKCE.


Sample Request (Curl): authorization_code Grant (non-PKCE)

The following command exchanges the authorization code K2MzvxY8nIRhNQYe for a set of tokens:

curl -X POST \
 https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code' \
  -d 'redirect_uri=https://documentation.akamai.com' \
  -d 'code=K2MzvxY8nIRhNQYe' \
  -d 'client_id=9e7f2429-496d-4437-b516-048472613cf9' \
  -d 'client_secret=yr64hdei39jkdktg'


Sample Request (Curl): authorization_code Grant (PKCE)

The following command uses the PKCE flow to exchange the authorization code K2MzvxY8nIRhNQYe for a set of tokens:

curl -X POST \
 https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code' \
  -d 'client_id=9e7f2429-496d-4437-b516-048472613cf9' \
  -d 'redirect_uri=https://documentation.akamai.com' \
  -d 'code=K2MzvxY8nIRhNQYe' \
  -d 'code_verifier=AdleUo9ZVcn0J7HkXOdzeqN6pWrW36K3JgVRwMW8BBQazEPV3kFnHyWIZi2jt9gA'


Sample Request (Curl): refresh_token Grant

The following command exchanges the refresh token iTsA4i2Px4TEzBrfLIvddjnDVBJxjPDuCARHH_Xk7EzdpGq5GPQcsxCWM2SxdlwU for an access token:

curl -X POST \
 https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=refresh_token' \
  -d 'refresh_token=iTsA4i2Px4TEzBrfLIvddjnDVBJxjPDuCARHH_Xk7EzdpGq5GPQcsxCWM2SxdlwU' \
  -d 'client_id=9e7f2429-496d-4437-b516-048472613cf9'


Sample Request (Curl): client_credentials Grant

The following command requests an access token for use with the Configuration APIs:

curl -X POST \
 https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token \
  -H 'Authorization: Basic YTIyYzk2MDQtN2IyNy00NjRmLWJmZjUDNiYTIyOTMyM2FmOmVJbTVnYkQ0QjF3NEswNGVYYUJ6dDVSRnhTaGMzcG1D' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=client_credentials' \
  -d 'scope=*:**'


Responses

200 OK

If your call to this endpoint succeeds, and depending on the type of grant you’ve requested, you'll get back a response that includes an access token, a refresh token, and an identity token:

{
   "access_token": "5na7KhMcUqnpoVDCRBX5na7Lwgh7L6qOaAlb1r2r_VKcemGgbh634rv261zbghfg6t",
   "refresh_token": "iTsA4i2Px4TEzBrfLIvddjnDVBJxjPDuCARHH_Xk7EzdpGq5GPQcsxCWM2SxdlwU",
   "expires_in": 3600,
   "token_type": "Bearer",
   "scope": "email openid profile",
   "id_token": "kyJhbGciOiJSUzI1NiIsImtpZCI6ImE5NjRhNjE3YTc0YjZjZWNlMDM4NTdkYWExZThlMTQ0ZDExMTMyY
TkiLCJ0eXAiOiJKV1QifQ.eyJhdF9oYXNoIjoiV1Y0STlVbjFWSi96Q25iRHVoWndIUSIsImF1ZCYwNC03YjI3LTQ2NGYtYmZ
mNS04M2JhMjI5MzIzYWYiXSwiYXV0aF90aW1lIjoxNTUzMDI3MjEzLCJleHAiOjE1NTMwMzA4MzksImdsb2JhbF9zdWIiOiJj
YXB0dXJlLXYxOi8vYjI3LTQ2NGYtYmZmNS04M2JhMjI5MzIzYWYiXSwiYXV0aF90aW1lIjoxNTUzMDI3bm5qZXl6eXJydDJub
TVkcmY1bmtuOC91c2VyLzc5OGQ2NTQwLWExYTYtNDFiNS1iZjcxLTg1YjY5NDFkY2E4MCIsImlhdCI6MTU1MzAyNzIzOSwiaX
NzIjoiaHR0cHM6Ly9hcGkubXVsdGkuZGV2Lm9yLmphbnJhaW4uY29tLzAwMDAwMDAwLTAwMDAtMzAwYjI3LTQ2NGYtYmZmNS0
4M2JhMjI5MzIzYWYiXSwiYXV0aF90aW1lIjoxNTUzMDI3NDFiNS1iZjcxLTg1YjY5NDFkY2E4MCJ9.TRaDPi2_a0Z2s6MYh3L
QEyTU5UkR1el6w_waPFeV2hZgv10pDHu6xVrAZUZwErU0_mSDbe9bJo5I_yuecgXZ_4Q1WNV0Z4zhTJT9ycpNeSwgPQcDGddh
8J1ybI0Rg6yM54OOcf6o_shqrQMGiiFirm9GrtPYjI3LTQ2NGYtYmZmNS04M2JhMjI5MzIzYWYiXSwiYXV0aF90aW1lIjoxNT
UzMDI319S83qGyLStH5db06iVjFahdNex0w39uQSHlTf7Ay0Acb0JOtMOk7JUC406wT5WT5Jz1qGV2q_ChvxdUCCnd2Vp8lNb
a3AyznkehABHeISkNYtJ6BKigQ"
}

Response Codes

The following table includes information about some of the response codes that you might encounter when calling this endpoint.

Response CodeDescription

400

Invalid_grant. Typically occurs if you pass an invalid authorization code or if the authorization code has expired. Authorization codes are valid only for a few minutes.



/{customerId}/profiles/oidc/userinfo

Back to top


Returns user profile information from the userinfo endpoint.

This endpoint includes the following methods:

  • GET

GET

Description

Returns user profile information for from the userinfo endpoint. See OpenID Connect Scopes and Claims for more information on how scopes are requested and whhy scopes may (or may not) be available from the userinfo endpoint.

URI Parameters

No additional parameters are required to call the /{customer_id}/oidc/userinfo endpoint.

Authentication

This endpoint requires Bearer authentication. To use this authentication, include the word Bearer in your Authorization header, followed by the value of the access token being used to retrieve the user data. For example:

Authorization: Bearer 03v-cgrdpp69hHXXIx56pRLyD98kldDxqEwI59MFCFGVuSkLmmkzgmfwm324Wli

Sample Request (curl)

The following command returns user information for the user granted the access token 03v-cgrdpp69hHXXIx56pRLyD98kldDxqEwI59MFCFGVuSkLmmkzgmfwm324Wli:

curl \
   https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/profiles/oidc/userinfo \
   -H 'Authorization: Bearer 03v-cgrdpp69hHXXIx56pRLyD98kldDxqEwI59MFCFGVuSkLmmkzgmfwm324Wli' 

Responses

200 OK

If your call to this endpoint succeeds, you'll get back the requested user profile information:

{
    "email": "karim.nafir@mail.com",
    "email_verified": true,
    "global_sub": "capture-v1://se-demos-gstemp.us-dev.janraincapture.com/79y4mqf2rt3bxs378kw5479xdu/GREG_DEMO/3c388dd9-5bcc-4883-9a91-d51129110a4a",
    "sub": "3c388dd9-5bcc-4883-9a91-d51129110a4a"
}

Error Codes

The following table includes information about some of the error codes that you could encounter when calling this endpoint.

Error Code

Description

400

Error Message: Invalid_request

Indicates that the subject and data authority do not match.

401

Error Message: Invalid_token

Typically occurs if you pass an invalid authorization code or if the authorization code has expired. Authorization codes are valid only for a few minutes.

If you encounter an error when calling this endpoint your error message will look similar to this:

{
   "error": "invalid_request",
   "error_description": "subject and data authority host do not match"
}



/{customerId}/login/.well-known/openid-configuration

Back to top


Returns the information found in the discovery document.

This endpoint includes the following methods:

  • GET

GET

Description

Returns the discovery document, a set of OIDC values that can be retrieved by a client; using these values enables OIDC clients to configure themselves. For example, you shouldn’t have to hard-code the token URL in a client. Instead, the client can simply connect to the well-known endpoint and retrieve the token URL itself.

The discovery document is more formally referred to as the “well-known endpoint;” that’s why the string well-known appears in the endpoint URL.

URI Parameters

No parameters are required in order to call the /{customer_id}/login/.well-known/openid-configuration endpoint.

Authentication

This endpoint does not require authentication. 

Sample Request (curl)

The following command returns information from the discovery document for the organization with the customer ID 00000000-0000-0000-0000-000000000000:


curl \
  https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/.well-known/openid-configuration

Responses

200 OK

If your call to this endpoint succeeds, you'll get back the configuration values found on the discovery document:


{
    "issuer": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login",
   "authorization_endpoint": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/authorize",
   "token_endpoint": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token",
   "introspection_endpoint": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token/introspect",
   "revocation_endpoint": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/token/revoke",
   "userinfo_endpoint": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/profiles/oidc/userinfo",
    "jwks_uri": "https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/jwk",
    "response_types_supported": [
        "code"
    ],
   "subject_types_supported": [
        "public"
    ],
   "id_token_signing_alg_values_supported": [
        "RS256"
    ],
   "grant_types_supported": [
       "authorization_code",
       "refresh_token"
    ],
   "token_endpoint_auth_methods_supported": [
       "client_secret_basic",
       "client_secret_post"
    ],
   "scopes_supported": [
        "openid",
        "profile",
        "email",
        "address",
        "phone"
    ],
   "claims_supported": [
        "sub",
        "iss",
       "auth_time",
        "acr",
        "name",
       "given_name",
        "address",
       "family_name",
       "middle_name",
       "preferred_username",
        "gender",
       "birthdate",
       "updated_at",
       "phone_number",
       "phone_number_verified",
        "email",
       "email_verified"
    ],
   "code_challenge_methods_supported": [
        "S256"
    
}


     

     


/{customerId}/login/jwk

Back to top


Returns information about the JSON web keys associated with the specified customer.

This endpoint includes the following methods:

  • GET

GET

Description

Returns information about the JSON web keys (JWK) associated with a customer. JSON web keys are public cryptographic keys used to verify the signatures on Hosted Login identity tokens.

URI Parameters

No parameters are required in order to call the /{customer_id}/login/jwk endpoint.

Authentication

This endpoint does not require authentication. 

Sample Request (curl)

The following command returns the JSON web keys associated with the customer ID 00000000-0000-0000-0000-000000000000:


curl https://v1.api.us.janrain.com/00000000-0000-0000-0000-000000000000/login/jwk 

Responses

200 OK

If your call to this endpoint succeeds, you'll get back a collection of JSON Web Keys similar to this:


{
    "keys": [
        {
            "use": "sig",
            "kty": "RSA",
            "kid": "51300370a8e1ac0a14a59cdd9c881d3f24c01f78",
            "alg": "RS256",
            "n": "w9OLNr_6sIuqr8OO3nPzorbv8tkmXC-m0k0O3W6gdk1QipvJ2pZkRSzD_iIWnEvYV11RuOBSAb7e_nU7mwNnxX6mORyJIEwnHKucBwaHQhuo56uVUjNTsRI6OuLB6REwxLM0ePPQPJNaXncWzt83oYdHU10VPmp5x0Sj-GjTvMpm2Y4I14KnFUXMEvIC-e5lf2P7q6KMXNw3PchEvmO5fVCgXf5-FgzDzEyn0qXrerdui4lGUtzcREPFksPNLNMlqp0XL5Kz1QLLkKDtR3dVjEtViEYJ6extcI-xFEV785hO4Ok36N99ht41EZk8ibrflNnYkJIEXAw_LKkmtxyZKw",
            "e": "AQAB"
        },
        {
            "use": "sig",
            "kty": "RSA",
            "kid": "f63eecd7318b6a6bcfae82f9607689756c6dd83e",
            "alg": "RS256",
            "n": "2kTH-jB0XDAb4yJy9rRMKNTNk4FEz7n3mbzj7nvupGvozyrpgHNFzSNW-Faxfo8v3cMdekd0-3S1ioNquAn9bbKZ8j2D4wK7rYtJgwOE8vnHkLUPAQuv_ymUgdgRAz7iQhsUN-vs8QLIDTddzEGnKWZASndLb-CYN_3eSWCDL7J8kQGkm9EI91OY1tKUUdIxlHpr90zAR36CFWWIJY1hpgFFnC1Po2r4nBtkBZD-SG_tmWB7fmWmF9v9MNnpmY00h3PsvUfzb6dSzLNt3H2ocSys7F5syaulRGLiKFiTalPPri_wAj-CPVfqiZuEys8PNTVd6T969PM4dIFdIsR0gw",
            "e": "AQAB"
        },
        {
            "use": "sig",
            "kty": "RSA",
            "kid": "a964a617a74b6cece03857daa1e8e144d11132a9",
            "alg": "RS256",
            "n": "7-LW8dGJKFsxU6ztkRA_qdhzvuHkoeWlRGL6ejqW9z_PxtDnQbLIpiy0vFm_DYAyNyFXt1EbuVMzESd4XRCKue4Lw2tGS_iiVQhlq7RkwAYG-hOkiiIHCcLVVCxtPm8gdmW-Cp4sdDozG0Yc99os-nyBtm2YzZ3ECAMsQsQVIjR03_JD3l1u79F4EzWcs2aBMOQ0NFDHqoQyk16Gf6Ww5QMXBtFhI508kYDMg71-0cxpssOrkztBBkxH1WPDpeliEAO91Sy1HDgXkuKdEuPkB3JxUqGXiw_UAez0a4XXBMFNkc5pV8byrKWokKmzNSgSfObqaRx13wOk5xjyVpyfHQ",
            "e": "AQAB"
        }
    ]
}