If you are building an app that does not have a server component, you’ll notice that it’s impossible to complete step three above to receive your
access_token
without also having to ship your client secret. You should never ship your client secret onto devices you don’t control. Then how do you get an
access_token
?
Well the smart folks in charge of the OAuth 2.0 spec anticipated this problem and created the Implicit Authentication Flow.
The only difference from the server-side flow is that the response_type is
token.
Authorization Endpoint |
---|
https://api.id.me/oauth/authorize |
GET
Name | Required | Description |
---|---|---|
client_id |
yes |
The client identifier received during app registration. It is automatically generated and located in your application dashboard. |
redirect_uri |
yes |
Where the user gets redirected after an authorizing an app. Set by the developer within the application dashboard. |
response_type |
yes |
|
scope |
yes |
A parameter that defines the group affiliation you are requesting permission to access. Possible values:
Note: Your account must first be set up with policies to enable these scopes to be accepted.
Contact partnersupport@id.me if you are receiving errors regarding an invalid scope. |
Example |
---|
https://api.id.me/oauth/authorize?client_id=[YOUR_CLIENT_ID]&redirect_uri=[YOUR_REDIRECT_URI]&response_type=token&scope=document |
Once the user has authenticated and authorized your app, we’ll redirect them to your
redirect_uri
with the
access_token
in the url fragment.
Redirect URI with access token |
---|
http://example.com/callback#access_token=da4ca0338450ae011a475bc105e0495c &token_type=bearer&expires_in=300
|
Simply grab the
access_token
off of the URL fragment and you’re good to go. If the user chooses not to grant access to your app, you will receive an error response.
See error examples here.