The Password grant type is used by first-party clients to exchange a user's credentials for an access token. Since this involves the client asking the user for their password, it should not be used by third party clients. In this flow, the user's username and password are exchanged directly for an access token. The application acts on behalf of the user. Refer to OAuth 2.0 spec for more details.
Fist step is to configure Client for Resource Owner Grant with secret and password grant type:
clientPUT /Client/myapp​secret: verysecretgrant_types:- password
Client will act on behalf of the user, which means Access Policies should be configured for User, not for Client.
You can configure Client for JWT tokens, set token expiration and enable refresh token:
attribute | options | desc |
auth.password.token_format | jwt | use access token in jwt format |
auth.password.token_expiration | int (seconds) | token expiration time from issued at |
auth.password.refresh_token | true/false | enable refresh_token |
auth.password.secret_required | true/false | require client secret for token |
Next step is to collect username & password and exchange username, password, client id and secret (if required) for Access Token.
Using Basic & form-url-encoded:
using-basicPOST /auth/tokenAuthorization: Basic base64(client.id, client.secret)Content-Type: application/x-www-form-urlencoded​grant_type=password&username=user&password=password
Or by JSON request:
json-requestPOST /auth/tokenContent-Type: application/json​{ "grant_type": "password","client_id": "myapp","client_secret": "verysecret","username": "user","password": "password"}
If provided credentials are correct, you get response with access token, user information and refresh token (if enabled):
token-responsestatus: 200​{"token_type": "Bearer","expires_in": 3600,"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODEiLCJzdWIiOiJ1c2VyIiwiaWF0IjoxNTU0NDczOTk3LCJqdGkiOiI0ZWUwZDY2MS0wZjEyLTRlZmItOTBiOS1jY2RmMzhlMDhkM2QiLCJhdWQiOiJodHRwOi8vcmVzb3VyY2Uuc2VydmVyLmNvbSIsImV4cCI6MTU1NDQ3NzU5N30.lCdwkqzFWOe4IcXPC1dIB8v7aoZdJ0fBoIKlzCRFBgv4YndSJxGoJOvIPq2rGMQl7KG8uxGU0jkUVlKxOtD8YA","refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODEiLCJzdWIiOiJwYXNzd29yZC1jbGllbnQiLCJqdGkiOiI0ZWUwZDY2MS0wZjEyLTRlZmItOTBiOS1jY2RmMzhlMDhkM2QiLCJ0eXAiOiJyZWZyZXNoIn0.XWHYpw0DysrqQqMNhqTPSdNamBM4ZDUAgh_VupSa7rkzdJ3uZXqesoAo_5y1naJZ31S92-DjPKtPEAyD_8PloA""userinfo": {"email": "user@mail.com","id": "user","resourceType": "User",},}
You can use access token in Authorization header for Aidbox API calls:
authorized-requestGET /PatientAuthorization: Bearer ZjQyNGFhY2EtNTY2MS00NjVjLWEzYmEtMjIwYjFkNDI5Yjhi
curl -H 'Authorization: Bearer ZjQyNGFhY2EtNTY2MS00NjVjLWEzYmEtMjIwYjFkNDI5Yjhi' /Patient
Aidbox creates Session resource for each Access Token, which can be closed with special endpoint DELETE /Session
with token in Authorization header:
close-sessionDELETE /SessionAuthorization: Bearer ZjQyNGFhY2EtNTY2MS00NjVjLWEzYmEtMjIwYjFkNDI5Yjhi
Session is just Resource and you can inspect and manipulate with sessions by standard Search & CRUD API for example get all sessions - GET /Session
​
​