Access to Koppeltaal
Last updated
Last updated
Koppeltaal requires that applications use the flow to request an access_token. The following diagram is used for this purpose
The FHIR documentation mentions multiple alg header values (e.g., RS384, ES384). Within the POC environment, we only support RS512.
iss
sub
exp
UNIX timestamp of now + 5 minutes
aud
jti
Random identifier, this is used by the auth server to prevent replay attacks. Use something like a GUID here.
Execute the following request:
POST https://auth-service.koppeltaal.headease.nl/oauth2/token
See the Response tab for an example response.
Content-Type*
string
application/x-www-form-urlencoded
client_assertion*
string
The signed JWT
client_assertion_type*
string
Always fill with
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
grant_type*
string
Always fill with
client_credentials
scope*
string
Content can be empty. The
scope
is set by the auth server based on the client's role
In the example response, the header should look like this:
The contents of the JWT and the OAuth request are described in detail . Koppeltaal has an exception to the scope parameter. It may be sent by the client, but its value is set by the auth server based on the client's role.
The above diagram shows that a JWT token is first compiled and . The following fields must be set:
Fill with the client_id value provided while
Fill with the client_id value provided while
Fill with
(value can be extracted from the )
As shown above in the 200 Response, the access_token is passed as part of the response. This access_token must be passed along as a Bearer token in the on every request to the Koppeltaal server. The format of the header is as follows:
The access_token has a relatively short lifetime. When the token expires, the Koppeltaal server will return a 401 error. The does not support a refresh_token. The application needs to redo steps 1 & 2.
