Implicit-Grant
This method is obsoleted, recommended method is Authorization Pin Grant
This authentication method is based on the Oauth2 Implicit Grant method.
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.
Authorization Request
The first step for the Client application is to notify the user (resource owner) that the application needs access to the users ImageVault application. The notification will display a information screen that informs the user and asks the user to either Deny or Allow access to ImageVault.
To display the dialog you need to access a page in the ImageVault UI and pass along the following query string parameters.
Parameter Name | Description |
---|---|
response_type | Defines the type of grant to be requested. Must be set to "token". |
client_id | The id of the client application that requests access to ImageVault (See OAuth Clients) |
redirect_uri | OPTIONAL. The uri where the response should be redirected. If omitted, the clients registered redirect_uri will be used. |
state | RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12. |
Example:
GET /oauth/authorize?response_type=token&client_id=myApplication&redirect_uri=https%3a%2f%2fmyserver.com HTTP/1.1
Host: imagevault.ui.server.com
Authorization Response
If the resource owner grants the access request, the authorization server issues an access token and delivers it to the client by adding
the following parameters to the fragment component of the redirection URI using the "application/x-www-form-urlencoded" format,
per Appendix B:
Parameter Name | Description |
---|---|
access_token | REQUIRED. The access token issued by the authorization server. |
token_type | REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive. |
expires_in | The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. |
state | REQUIRED if the "state" parameter was present in the client authorization request. The exact value received from the client. |
url | The url for the Core service endpoint that accepts Access token requests. (see below) |
For example, the authorization server redirects the user-agent by sending the following HTTP response (with extra line breaks for display purposes only):
HTTP/1.1 302 Found
Location: https://client.example.com/cb?#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer&expires_in=3600&state=xyz&url=https%3a%2f%2fimagevault.core.server.com
Error response
If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI.
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the fragment component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:
The parameter description for the error response can be found in the 4.2.2.1 Error response section.
For example, the authorization server redirects the user-agent by sending the following HTTP response:
HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz