How 3scale supports oAuth v1 and v2

3scale & oAuth Integration

3scale & oAuth Integration

  1. The App developer (consumer of  the  API) gets its client_id and client_secret via the buyer portal (in case of oAuth v1 would be consumer_key, etc.). These keys get provisioned after the account is validated, or by the provider through their portal, or via the Account API (e.g. Legacy systems or buyer portals not based on 3scale’s).

  3. The App developer does the requests to the API as per standard oAuth, any library is supported since he knows its client_id and client_secret. Regardless if it’s a call to the API or or the GetAccessToken the client_id is always sent to the API provider (even once the access_token has been granted). The request is signed with his client_secret.

  5. The API provider calls 3scale’s backend with the client_id from the request in addition to all the metrics/methods that need to be validated according to the rules and limits defined on the plan the App developer is in. 3scale returns whether or not the API request is valid plus the current utilization of the limits, access control, etc. 3scale also returns the client_secret so that the API provider can run the final validation for tampering.

  7. The API must check that the md5/mac-­sha1 of the request (body, nonce, etc.) with the client_secret returned from 3scale matches the signature sent by the requester so that it can be sure of the origin and that there was no request tampering.