Securing API access with scoped tokens

By default, Arvados API tokens grant unlimited access to a user account, and admin account tokens have unlimited access to the whole system. If you want to grant restricted access to a user account, you can create a “scoped token” which is an Arvados API token which is limited to accessing specific APIs.

One use of token scopes is to grant access to data, such as a collection, to users who do not have an Arvados accounts on your cluster. This is done by creating scoped token that only allows getting a specific record. An example of this is creating a collection sharing link.

Another example is situations where admin access is required but there is risk of the token being compromised. Setting a scope prevents the token from being used for any action other than the specific action the token is intended for. For example, synchronizing user accounts on a shell node.

Defining scopes

A “scope” consists of a HTTP method and API path. A token can have multiple scopes. Token scopes act as a whitelist, and the API server checks the HTTP method and the API path of every request against the scopes of the request token. Scopes are also described on the API Authorization page of the API documentation.

These examples use /arvados/v1/collections, but can be applied to any endpoint. Consult the API documentation to determine the endpoints for specific methods.

The scope ["GET", "/arvados/v1/collections"] will allow only GET or HEAD requests for the list of collections. Any other HTTP method or path (including requests for a specific collection record, eg a request with path /arvados/v1/collections/zzzzz-4zz18-0123456789abcde) will return a permission error.

A trailing slash in a scope is signficant. The scope ["GET", "/arvados/v1/collections/"] will allow only GET or HEAD requests starting with /arvados/v1/collections/. A request for an individual record path /arvados/v1/collections/zzzzz-4zz18-0123456789abcde) is allowed but a request to list collections (/arvados/v1/collections) will be denied because it does not end with / (API requests with a trailing / will have the slash stripped before the scope is checked.)

The scope can include an object uuid. The scope ["GET", "/arvados/v1/collections/zzzzz-4zz18-0123456789abcde"] only permits requests to read the record zzzzz-4zz18-0123456789abcde.

Since a token can have multiple scopes, use [["GET", "/arvados/v1/collections"], ["GET", "/arvados/v1/collections/"]] to allow both listing collections and fetching individual collection records. This will reject requests to create or change collections, or access any other API method.

Object create calls use the POST method. A scope of ["POST", "/arvados/v1/collections"] will allow creating collections, but not reading, listing or updating them (or accessing anything else).

Object update calls use the PATCH method. A scope of ["PATCH", "/arvados/v1/collections/"] will allow updating collections, but not listing or creating them. (Note: while GET requests are denied an object can be read indirectly by using an empty PATCH which will return the unmodified object as the result).

Similarly, you can use a scope of ["PATCH", "/arvados/v1/collections/zzzzz-4zz18-0123456789abcde"] to restrict updates to a single collection.

There is one special exception to the scope rules: a valid token is always allowed to issue a request to GET /arvados/v1/api_client_authorizations/current regardless of its scopes. This allows clients to reliably determine whether a request failed because a token is invalid, or because the token is not permitted to perform a particular request. The API server itself needs to be able to do this to validate tokens issued by other clusters in a federation.

Creating a scoped token

A scoped token can be created at the command line:

$ arv api_client_authorization create --api-client-authorization '{"scopes": [["GET", "/arvados/v1/collections"], ["GET", "/arvados/v1/collections/"]]}'
{
 "kind":"arvados#apiClientAuthorization",
 "etag":"9yk144t0v6cvyp0342exoh2vq",
 "uuid":"zzzzz-gj3su-bizbsw0mx5pju3w",
 "owner_uuid":"zzzzz-tpzed-fr97h9t4m5jffxs",
 "created_at":"2020-03-12T20:36:12.517375422Z",
 "modified_by_user_uuid":null,
 "modified_at":null,
 "api_token":"5a74htnoqwkhtfo2upekpfbsg04hv7cy5v4nowf7dtpxer086m",
 "created_by_ip_address":null,
 "expires_at":null,
 "last_used_at":null,
 "last_used_by_ip_address":null,
 "scopes":[
  [
   "GET",
   "/arvados/v1/collections"
  ],
  [
   "GET",
   "/arvados/v1/collections/"
  ]
 ]
}

The response will include api_token field which is the newly issued secret token. It can be passed directly to the API server that issued it, or can be used to construct a v2 token. A v2 format token is required if the token will be used to access other clusters in an Arvados federation. An Arvados v2 format token consists of three fields separate by slashes: the prefix v2, followed by the token uuid, followed by the token secret. For example: v2/x1u39-gj3su-bizbsw0mx5pju3w/5a74htnoqwkhtfo2upekpfbsg04hv7cy5v4nowf7dtpxer086m.

---

Previous: Synchronizing from external sources Next: Automatic logout and token expiration