Manage Allowed Response Types

In an authorization request, the response_type parameter specifies the item (or items) clients expect to get back from the authorization server following a successful authentication. (You can read more about response types in this article.) In Hosted Login, the response types a client can request are dictated by login policies and by the allowedResponseTypes property. 

However, even though allowedResponseTypes is a login policy property, the allowed response types can’t be managed (or even viewed) by using the /loginPolicies/{loginPolicyId} endpoint. Instead, anyone who needs to work with response types must use the /loginPolicies/{loginPolicyId}/allowedResponseTypes endpoint detailed below.

This endpoint supports the following methods:



GET


Description

Returns information about the response types that can be used in with the specified login policy. Allowed response types include the following:

  • code. The authorization endpoint issues an authorization code that must be exchanged at the token endpoint for an access token, a refresh token, and an identity token.
  • id_token. The authorization endpoint issues an identity token, without requiring the user to engage with the token endpoint.
  • token. The authorization endpoint issues a an access token, without requiring the user to engage with the token endpoint.

Note that some response types can be combined: for example, you can request both an access token and an identity token (response_type=token id_token). See the article Supported Response Types for more information.

URI Parameters

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

Parameter

Type

Required

Description

{customerId}

string

Yes

Unique identifier of the organization associated with the login policy.

{loginPolicyId}

string

Yes

Unique identifier for the login policy.


Authentication

This endpoint requires token-based authentication. To obtain an access token, you must employ a configuration client (using the client ID as the username and the client secret as the password) to access the /{customerId}/login/token endpoint. The access token returned from the token endpoint is then used in the Authorization header of your API call. For example, if you get back the access token Ki712dpGq5GPQcsxMHY6ShHY7wU_iTs0o9dPx4TEzf5yLIvddjnDVBJxjPDucf5YVB then your Authorization header will look like this when using Curl:

-H 'Authorization: Bearer Ki712dpGq5GPQcsxMHY6ShHY7wU_iTs0o9dPx4TEzf5yLIvddjnDVBJxjPDucf5YVB'

In Postman, set the Authorization Type to Bearer and use the access token as the value of the Token field.


Sample Request (curl)

The following command returns information about the response types specified in the login policy 1e1ab726-f4b5-4bad-ba45-877027af4097:

curl -X GET \
'https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/config/loginPolicies/1e1ab726-f4b5-4bad-ba45-877027af4097/allowedResponseTypes' \
  -H 'Authorization: Bearer dgqJbjCmon__P9OXLz5ulJtpS-jupleB-MBejblVMZHS8Nc-EeMSl91_b76WhtdA' 


Responses

200 OK

If your call to this endpoint succeeds, you’ll get back a collection consisting of the response types allowed by the specified login policy. For example:

[
    "code",
    "id_token"
]


Error Response Codes

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

Response Code

Description

403

Forbidden. Typically occurs when you make a call using an invalid configuration token. This is usually because the token has expired (configuration tokens have a maximum lifetime of 1 hour). However, it’s also possible that the token wasn’t issued a scope capable of accessing push claim information. See the article  API Security for Configuration for more information.

404

Not found. The specified login policy could not be found. This generally occurs because you referenced an invalid policy ID or customer ID when making your API call.



PUT

Back to top


Description

The PUT method enables you to specify the response types supported by a given login policy; those policies can support any combination of the following response types:

  • code. The authorization endpoint issues an authorization code; that code must the be exchanged at the token endpoint for an access token, a refresh token, and an identity token.
  • id_token. The authorization endpoint issues an identity token, without requiring the user to engage with the token endpoint.
  • token. The authorization endpoint issues an access token, without requiring the user to engage with the token endpoint.

When updating the allowed response types, your API call must specify all the desired response types: that’s because the response types included in the body parameter replace the current set of response types. For example, suppose your login policy currently contains these two response types;

  • code
  • token

Because you want to add id_token to the set of allowed response types, you use a body parameter that looks like this:

[
    "id_token"
]

After you make your API call, your login policy will contain the following set of allowed response types:

  • id_token

Why did the code and token types disappear?That’s because the previous set of response types (code and token) has been replaced by the new set (id_token) specified in the API call. To add id_token to the set of allowed response types your body parameter needs to include not only the new response type but all of your existing response types as well:

[
    "code",
    "id_token",
    "token"
]

In addition, be sure to format your request as an array: that means enclosing the allowed response types in square brackets. For example, suppose your body parameter looks like this:

"token"

In that case, your API call will fail with the following error:

{
    "errors": "('allowedResponseTypes',) Incorrect allowedResponseTypes: [t, o, k, e, n]! Accepts only [none, code, id_token, token]"
}

Instead, enclose the values in square brackets:

[
    "token"
]

This is required even if, as illustrated in the preceding example, your array consists of a single response type.

URI Parameters

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

Parameter

Type

Required

Description

{customerId}

string

Yes

Unique identifier of the organization associated with the login policy.

{loginPolicyId}

string

Yes

Unique identifier for the login policy.


Authentication

This endpoint requires token-based authentication. To obtain an access token, you must employ a configuration client (using the client ID as the username and the client secret as the password) to access the /{customerId}/login/token endpoint. The access token returned from the token endpoint is then used in the Authorization header of your API call. For example, if you get back the access token Ki712dpGq5GPQcsxMHY6ShHY7wU_iTs0o9dPx4TEzf5yLIvddjnDVBJxjPDucf5YVB then your Authorization header will look like this when using Curl:

-H 'Authorization: Bearer Ki712dpGq5GPQcsxMHY6ShHY7wU_iTs0o9dPx4TEzf5yLIvddjnDVBJxjPDucf5YVB'

In Postman, set the Authorization Type to Bearer and use the access token as the value of the Token field.


Sample Request (curl)

The following command assigns all three of the supported response types to the login policy 1e1ab726-f4b5-4bad-ba45-877027af4097:

curl -X PUT \
'https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/config/loginPolicies/1e1ab726-f4b5-4bad-ba45-877027af4097/allowedResponseTypes' \
  -H 'Authorization: Bearer dgqJbjCmon__P9OXLz5ulJtpS-jupleB-MBejblVMZHS8Nc-EeMSl91_b76WhtdA' \
  -H 'Content-Type: application/json' \
  --data-raw '[
    "code",
    "id_token",
    "token"
]'


Responses

200 OK

If your API call succeeds, you’ll get back an updated list of response types supported by the login policy:

[
    "code",
    "id_token",
    "token"
]


Error Response Codes

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

Response Code

Description

400

Bad request. Typically occurs if your API call includes an invalid response type. For example, if your call includes a response type named bob you’ll get back the following error:

{
    "errors": "('allowedResponseTypes',) Incorrect allowedResponseTypes: [bob]! 
    Accepts only [none, code, id_token, token]"
}

This error also occurs if your API call includes a total blank body parameter (i.e., one with no allowed response types).

403

Forbidden. Typically occurs when you make a call using an invalid configuration token. This is usually because the token has expired (configuration tokens have a maximum lifetime of 1 hour). However, it’s also possible that the token wasn’t issued a scope capable of accessing response type information. See the article API Security for Configuration for more information.

404

Not found. The specified login policy could not be found. This generally occurs because you referenced an invalid policy ID or customer ID when making your API call.