- OAuth 2.0 is the industry-standard protocol for authorization
- Understanding the OAuth2.0 standard can be complex, for the main reason being how many different ways OAuth2.0 can be implemented for varying requirements
- In this article we will focus on the Client Credentials Flow
- Other OAuth2.0 flows include:
- Authorization Code Flow
- Implicit Flow
- Resource Owner Flow
- When in doubt, reference the OAuth2.0 spec -> here
- Log in to the Centrify Application Services Portal as an Administrator
- Switch to Admin Portal
- Click on "Apps"
- Click on "Add Web Apps"
5. Click the "Custom" tab
6. Add OAuth2 Client Application
7. Select "Yes" when asked "Do you want to add this application?"
8. Close "Add Web Apps" Pop-Up
9. Begin Application Configuration
10. Within "Description" section, define a unique Application ID
11. Navigate to "General Usage"
12. Define General Usage as both "Confidential" & "Must be OAuth Client"
13. Skip the link to create a Service User, we'll come back to that later
14. Navigate to "Tokens"
15. Define "Token Type" as "JwtRS256" (256 encrypted "JSON Web Token)
16. Define "Auth Methods" as "Client Creds"
17. Select a desired token lifetime (how long it's valid for)
18. Navigate to "Scopes"
19. Define "Scopes" for what is protected and requires an auth/bearer token
20. In this example we are protecting the tenant APIs exposed by the issuer: (https://aaq0180.my.centrify.com)
21. Select "Add" under "Scope definitions"
22. Give your scope definitions a Name, Description & Regular Expression Filter
23. "RedRock/query" is the standard API syntax for Applications to query specified Centrify Platform
(Learn more about using queries -> here)
24. Click "Save"
25. Our defined scope now restricts access for running report queries programmaticly
26. Navigate to "User Access"
27. For this example, we're going to restrict query access to only Service Accounts/Users
28. Click "Save" your OAuth2 Client Application Configuration is complete for now
29. Now we need to create a Service User that will act as our Confidential Client
30. Navigate under "Core Services">"Users">"Add User"
31. Create the user by supplying Login Name, Display Name, Password Type,
32. Ensure that user status is defined as both a Service User & OAuth Confidential Client
33. Select "Create User"
34. If you haven't already done so, create a Service_Users Role
35. Now make sure our newly created service user is included under "Members" of our Service_Users Role
36. Under "Administrative Rights" make sure the role includes "Read Only System Administration"
37. Under "Assigned Applications" make sure our newly created OAuth2 Client App is added
38. Click "Save" to complete Role configuration
39. Now we can create a "Bearer Token" to be used to invoke our protected APIs
40. Navigate back to "Apps" and select our newly created OAuth2 Client Application
41. Under the "Actions" dropdown menu, select "Create Bearer Token"
42. Here, you will have to supply the client_id & secret that you established as part of your Service User/Confidential Client
43. Select "Get Token"
44. If the ClientID & Secret are validated as correct, a bearer token will be generated and displayed
45. Select "Copy" to capture/copy token to be used later for authorization
46. Now that we have our Token, we can do a quick recap and put it to the test!
47. Reference below Video on how to use this token and how to validate our setup is correct
48. [Updated March 2018] An alternative and more efficient way of obtaining an authorization token is to retrieve the oauth2 token programatically instead of manually through the User Interface. While several grant_types per the OAuth2.0 spec can achieve this, in our example we will use the grant_type of client_credentials. As per the spec we need to supply the grant_type, client_id & client_secret in the HTTP Post Header. In our example we will use Postman to invoke the oauth2 token endpoint, which requires the request parameters to be passed in the request body. Using a confidential client defined in step 33 we can obtain a token. In this example we will use a separate confidential client or "service user" api_user@eddie_welch_01 but you'll notice they are both attached to the same role, assoicaed with the my_oauth_client AppID. The URL Token Endpoint is as follows:
In our example we will use:
The AppID can be found in the admin console here:
Here is our Postman Request Headers:
Here is our Postman Request Body which includes our 3 required parameters:
Here is our Postman Response, which includes our Oauth Access Token: