Now when you run `vault auth -methods`, the Okta backend is available:
```
Path Type Description
okta/ okta
token/ token token based credentials
```
To use the Okta auth backend, it must first be configured for your Okta account.
The configuration options are categorized and detailed below.
Configuration is written to `auth/okta/config`.
### Connection parameters
*`organization` (string, required) - The Okta organization. This will be the first part of the url `https://XXX.okta.com` url.
*`token` (string, optional) - The Okta API token. This is required to query Okta for user group membership. If this is not supplied only locally configured groups will be enabled. This can be generated from http://developer.okta.com/docs/api/getting_started/getting_a_token.html
*`base_url` (string, optional) - The Okta url. Examples: `oktapreview.com`, The default is `okta.com`
This adds the Okta user "tesla" to the "engineers" group, which maps to
the "foobar" Vault policy.
Finally, we can test this by authenticating:
```
$ vault auth -method=okta username=tesla
Password (will be hidden):
Successfully authenticated! The policies that are associated
with this token are listed below:
bar, foo, foobar
```
## Note on Okta Group's
Groups can only be pulled from Okta if an API token is configured via `token`
## Note on policy mapping
It should be noted that user -> policy mapping (via group membership) happens at token creation time. And changes in group membership in Okta will not affect tokens that have already been provisioned. To see these changes, old tokens should be revoked and the user should be asked to reauthenticate.