The Three-Legged OAuth flow is a secure authorization process allowing an application to access a user’s resources. This process involves three parties: the end-user (resource owner), the client (third-party application), and the server (authorization server).
- Authorization Request: The Client Application requests authorization from the Resource Owner to access protected resources.
- Authorization Grant: The Resource Owner approves the request and provides the Client Application with an Authorization Grant.
- Access Token Request: The Client Application sends the Authorization Grant to the Authorization Server and requests an Access Token.
- Access Token Issuance: The Authorization Server authenticates the Client Application, validates the Authorization Grant, and issues an Access Token.
- Resource Request: The Client Application requests access to the protected resource from the Resource Server, including the Access Token.
- Token Validation and Resource Access: The Resource Server validates the Access Token.
- Resource Delivery: After successful validation, the Resource Server returns the requested protected resource to the Client Application.
Steps in the Three-Legged OAuth Flow:
- Get an authorization code
- Exchange the authorization code for an access token
- Access Protected Resources
Request authorization code
The client application redirects the user to the authorization server to request authorization. The server prompts the user to log in and approve the requested permissions.
- Use the Client Key and Secret from your sandbox app to populate the related variables in the "Sandbox Credentials" environment group in Postman.
- To get an authorization code, make a request to the “/bc-authorize” endpoint. Vodafone's API validates the client_id provided. Use the following parameters in the request. All parameters are required:
|
Parameter |
Description |
|---|---|
| Authorization | Encoded credentials (Consumer Key and Consumer Secret) used to authenticate the client. |
| X-Correlator | A unique identifier for tracking requests across systems for auditing or debugging. |
| Content-Type | Specifies the format of the request body. Typically set to application/x-www-form-urlencoded. |
| login_hint | Information to help identify the user (e.g., their phone number, email, or another identifier). |
Authorization request example
curl -X 'POST' \
'https://example.com/v1/bc-authorize' \
-H 'Authorization: Basic [[Authorization-masked-secret]]' \
-H 'X-Correlator: [[X-Correlator-masked]]' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'login_hint=[[Login-hint-masked]]'Authorization response example
HTTP/1.1 200 OK
{
auth_req_id": "[[Authorization-request-id-masked]]",
"expires_in": 300,
"interval": 0
}
Request access token
To use this API, you must exchange the auth_req_id for an access token. The token is valid for 59 minutes and 59 seconds and can be used for multiple requests.
If the request is valid, the API returns an access_token, along with expiry and scope information. This access token can then be used in one or more requests as long as it remains valid. The API will return an error message if the request is invalid.
To exchange the auth_req_id for an access token:
- Make a “/token” request. Use the following parameters in the request. All parameters are required:
|
Parameter |
Description |
|---|---|
| accept | Specifies the response format expected from the server. Typically set to application/json. |
| X-Correlator | A unique identifier for tracking requests across systems for auditing or debugging. |
| Content-Type | Specifies the format of the request body. Typically set to application/x-www-form-urlencoded. |
| auth_req_id | The unique identifier for the authentication request issued during the authorization step. |
Token request example
curl -X 'POST' \
'https://example.com/openIDConnectCIBA/v1/token' \
-H 'accept: application/json' \
-H 'X-Correlator: [[X-Correlator-masked]]' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'auth_req_id=[[Authorization-req-id-masked]]'Token response example
HTTP/1.1 200 OK
{
"access_token": "[[Access-token-masked]]",
"token_type": "Always \"Bearer\"",
"expires_in": 3599,
"id_token": "[[ID-token-masked]]"
}
Access the Protected Resource
Use the access token in the Authorization header to access the API’s protected endpoints.
