Comment on page
Eko OpenID Flow
- Step 1 - Redirect users to authenticate to Eko
- Step 2 - Obtain authentication code from Eko
- Step 3- Request tokens using authentication code
- Step 4- Get user profile using access token (optional)
When a user sends an HTTP request to a third party app, the app must do two things
- 1.The app must create a unique session token that holds the state between your app and the user's client. You later match this unique session token with the authentication response (returned by the Eko Auth) to verify that the user is making the request and not a malicious attacker. These tokens are often referred to as cross-site request forgery (CSRF) tokens (One good choice for a state token is a string of 30 or so characters constructed using a high-quality random-number generator)
- 2.The app then redirect the user to Eko Auth endpoint obtained after the registration. The parameters described must be passed along with the HTTP request.
After Eko Auth receives the request with parameters from the browser, it will do as follows
- 1.Eko Auth verifies the session cookie. (Actually, we must prompt the user to log in if he is not, but we assumed that the user is already logged in)
- 2.Eko Auth verifies the “redirect_uri” which must match the one given to Eko in the registration step. The “client_id” must be valid. The “response_type” must be “code”. The “scope” must contain “openid” or “openid profile”. Other unknown parameter must be ignored. You will received a return error response if these conditions are not valid.
- 3.Eko Auth generates an authentication code and redirect Eko App to the “redirect_uri” along with that “code”.
After the app receives the “code” and “state” from Eko Auth, it must verify that the state in user’s session or cookie matches with the state received from Eko Auth. This mechanism is used to prevent CSRF.
Example of HTTP request
The third-party app uses the “code” to derive an “access token” by sending a request to Eko Auth. The third-party app must authenticate to the Eko Auth using the HTTP Basic method. Attach an ‘Authorization’ header as described in HTTP Basic Authentication and OAuth 2.0 section 2.3.1. Briefly, the encoded string is derived from base64(client_id + “:” + client_secret).
Example of HTTP request
curl -X POST \
-H 'Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW' \
-H 'Content-Type: application/x-www-form-urlencoded' \
After Eko Auth receives the request from the third-party app, it will
- 1.Verify the authorization header (client_id & client_secret).
- 2.Verify the “redirect_uri”. It must match the one during registration.
- 3.Verify the “grant_type” which must be “authorization_code”.
- 4.Verify the “code”. If the authentication code is found in the database, the response to the third-party app will be the following specification.
Example of HTTP response
Cache-Control: no-cache, no-store
"scope": "openid profile",
"id_token":"eyJ0 ... NiJ9.eyJ1c ...
I6IjIifX0.DeWt4Qu ... ZXso"
The ID Token is a security token that contains claims about the authentication of a user by Eko Auth when using a Client, and potentially other requested Claims. The ID Token is represented as a JWT. This link provides a good tutorial on how to create one using JWT format. The ID Token is signed with client secret and will expire in one hour. If scope is set to “openid”
After the third-party app receives the response from Eko Auth, it should
- 1.Decode the ID token
- 2.The third-party app does not have to verify the signature of the received ID token as it can be confident that it is communicating with Eko's server directly. However, an ID token signature can be verified by using client secret.
- 3.The third-party app must verify the ID token claims.
- 1.“iss” must be matched with the Eko Auth url.
- 2.“aud” must be the third-party app’s client_id.
- 3.“exp” must be larger than current UNIX timestamp value.
- 4.If “iat” is too old, the third-party app can reject this token. To decide how old the token should be rejected is depended on the app itself.
- 4.The third-party app can now consume the ID token and access token. The use of access token will not be covered in this document.
- 5.The third-party app can now allow users to access the service.
In case the third party app needs to get more user information such as user profile, it can send an HTTP request with an access token in the Authorization Header to Eko Auth to get the user information.
Example of HTTP request
curl -X GET \
-H 'Authorization: Bearer SlAV32hkKG' \
Eko Auth verifies the access token, if valid, then returns additional information to the third party app in JSON format. The following is an example of returned value. The returned fields might vary depending on the profile information of users.
Example of HTTP response body in JSON format
"email": "[email protected]",
We allow customer to view or download user profile picture on Eko.
- 1.Eko OAuth 2.0 Phase 1 Specification