token-authentication-services.asciidoc 2.9 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. [role="xpack"]
  2. [[token-authentication-services]]
  3. === Token-based authentication services
  4. The {stack-security-features} authenticate users by using realms and one or more token-based
  5. authentication services. The token-based authentication services are used for
  6. authentication and for the management of tokens. These tokens can be used as
  7. credentials attached to requests that are sent to {es}. When {es} receives a request
  8. that must be authenticated, it consults first the token-based authentication
  9. services then the realm chain.
  10. The {security-features} provide the following built-in token-based authentication
  11. services, which are listed in the order they are consulted:
  12. _token-service_::
  13. The token service uses the <<security-api-get-token,get token API>> to
  14. generate access tokens and refresh tokens based on the OAuth2 specification.
  15. The access token is a short-lived token. By default, it expires after 20 minutes
  16. but it can be configured to last a maximum of 1 hour. It can be refreshed by
  17. using a refresh token, which has a lifetime of 24 hours. The access token is a
  18. bearer token. You can use it by sending a request with an `Authorization`
  19. header with a value that has the prefix "Bearer " followed by the value of the
  20. access token. For example:
  21. +
  22. --
  23. [source,shell]
  24. --------------------------------------------------
  25. curl -H "Authorization: Bearer dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==" http://localhost:9200/_cluster/health
  26. --------------------------------------------------
  27. // NOTCONSOLE
  28. --
  29. _api-key-service_::
  30. The API key service uses the
  31. <<security-api-create-api-key,create API key API>> to generate API keys.
  32. By default, the API keys do not expire. When you make a request to create API
  33. keys, you can specify an expiration and permissions for the API key. The
  34. permissions are limited by the authenticated user's permissions. You can use the
  35. API key by sending a request with an `Authorization` header with a value that
  36. has the prefix "ApiKey " followed by the credentials. The credentials are the
  37. base64 encoding of the API key ID and the API key joined by a colon. For example:
  38. +
  39. --
  40. [source,shell]
  41. --------------------------------------------------
  42. curl -H "Authorization: ApiKey VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw==" http://localhost:9200/_cluster/health
  43. --------------------------------------------------
  44. // NOTCONSOLE
  45. --
  46. Depending on your use case, you may want to decide on the lifetime of the tokens
  47. generated by these services. You can then use this information to decide which
  48. service to use to generate and manage the tokens. Non-expiring API keys may seem
  49. like the easy option but you must consider the security implications that come
  50. with non-expiring keys. Both the _token-service_ and _api-key-service_ permit
  51. you to invalidate the tokens. See
  52. <<security-api-invalidate-token,invalidate token API>> and
  53. <<security-api-invalidate-api-key,invalidate API key API>>.