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
- PUT
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. |