21장. Token-Based Authentication
OAuth 2 is used for token-based authentication. You can manage OAuth tokens and applications, a server-side representation of API clients used to generate tokens. By including an OAuth token as part of the HTTP authentication header, you can authenticate yourself and adjust the degree of restrictive permissions in addition to the base RBAC permissions.
For more information on the OAuth2 specification, see The OAuth 2.0 Authorization Framework.
For more information on using the manage utility to create tokens, see Token and session management.
21.1. Managing OAuth 2 Applications and Tokens 링크 복사링크가 클립보드에 복사되었습니다!
Applications and tokens can be managed as a top-level resource at /api/<version>/applications and /api/<version>/tokens. These resources can also be accessed respective to the user at /api/<version>/users/N/<resource>. You can create applications by making a POST to either api/<version>/applications or /api/<version>/users/N/applications.
Each OAuth 2 application represents a specific API client on the server side. For an API client to use the API via an application token, it must first have an application and issue an access token. Individual applications are accessible through their primary keys in: /api/<version>/applications/<pk>/.
The following is a typical application:
{
"id": 1,
"type": "o_auth2_application",
"url": "/api/v2/applications/2/",
"related": {
"tokens": "/api/v2/applications/2/tokens/"
},
"summary_fields": {
"organization": {
"id": 1,
"name": "Default",
"description": ""
},
"user_capabilities": {
"edit": true,
"delete": true
},
"tokens": {
"count": 0,
"results": []
}
},
"created": "2018-07-02T21:16:45.824400Z",
"modified": "2018-07-02T21:16:45.824514Z",
"name": "My Application",
"description": "",
"client_id": "Ecmc6RjjhKUOWJzDYEP8TZ35P3dvsKt0AKdIjgHV",
"client_secret": "7Ft7ym8MpE54yWGUNvxxg6KqGwPFsyhYn9QQfYHlgBxai74Qp1GE4zsvJduOfSFkTfWFnPzYpxqcRsy1KacD0HH0vOAQUDJDCidByMiUIH4YQKtGFM1zE1dACYbpN44E",
"client_type": "confidential",
"redirect_uris": "",
"authorization_grant_type": "password",
"skip_authorization": false,
"organization": 1
}
Where name is the human-readable identifier of the application. The rest of the fields, like client_id and redirect_uris, are mainly used for OAuth2 authorization, which is covered in Using OAuth 2 Token System for Personal Access Tokens (PAT).
The values for the client_id and client_secret fields are generated during creation and are non-editable identifiers of applications, while organization and authorization_grant_type are required upon creation and become non-editable.
21.1.1. Access Rules for Applications 링크 복사링크가 클립보드에 복사되었습니다!
Access rules for applications are as follows:
- System administrators can view and manipulate all applications in the system.
- Organization administrators can view and manipulate all applications belonging to Organization members.
- Other users can only view, update, and delete their own applications, but cannot create any new applications.
Tokens, on the other hand, are resources used to authenticate incoming requests and mask the permissions of the underlying user.
There are two ways to create a token:
-
POST to the
/api/v2/tokens/endpoint and set theapplicationandscopefields to point to the related application and specify the token scope. -
POST to the
/api/v2/applications/<pk>/tokens/endpoint with thescopefield (the parent application is automatically linked).
Individual tokens are accessible through their primary keys at /api/<version>/tokens/<pk>/.
The following is an example of a typical token:
{
"id": 4,
"type": "o_auth2_access_token",
"url": "/api/v2/tokens/4/",
"related": {
"user": "/api/v2/users/1/",
"application": "/api/v2/applications/1/",
"activity_stream": "/api/v2/tokens/4/activity_stream/"
},
"summary_fields": {
"application": {
"id": 1,
"name": "Default application for root",
"client_id": "mcU5J5uGQcEQMgAZyr5JUnM3BqBJpgbgL9fLOVch"
},
"user": {
"id": 1,
"username": "root",
"first_name": "",
"last_name": ""
}
},
"created": "2018-02-23T14:39:32.618932Z",
"modified": "2018-02-23T14:39:32.643626Z",
"description": "App Token Test",
"user": 1,
"token": "*************",
"refresh_token": "*************",
"application": 1,
"expires": "2018-02-24T00:39:32.618279Z",
"scope": "read"
},
For an OAuth 2 token, the only fully editable fields are scope and description. The application field is non-editable on update, and all other fields are entirely non-editable, and are auto-populated during creation, as follows:
-
userfield corresponds to the user the token is created for, and in this case, is also the user creating the token. -
expiresis generated according to the automation controller configuration settingOAUTH2_PROVIDER. -
tokenandrefresh_tokenare auto-generated to be non-clashing random strings.
Both application tokens and personal access tokens are shown at the /api/v2/tokens/ endpoint. The application field in the personal access tokens is always null. This is a good way to differentiate the two types of tokens.
21.1.2. Access rules for tokens 링크 복사링크가 클립보드에 복사되었습니다!
Access rules for tokens are as follows:
- Users can create a token if they are able to view the related application and can also create a personal token for themselves.
- System administrators are able to view and manipulate every token in the system.
- Organization administrators are able to view and manipulate all tokens belonging to Organization members.
- System Auditors can view all tokens and applications.
- Other normal users are only able to view and manipulate their own tokens.
Users can only view the token or refresh the token value at the time of creation.