This provides the '/authorize', '/token' and '/attributes/values' endpoints. Details of the limitations in this mock of each endpoint are listed below.
This mock allows you to request a mix of scopes for which data you want to simulate requesting:
Service customers should direct the user to the above URL. In production the user will go through details verification (e.g. scope=openid scotaccount.email scotaccount.address) or authentication (scope=openid). In this mock a webpage with links to simulated outcomes is returned. Once an outcome has been reached by the user or selected from the mock, the user is redirected to the redirect_uri with the results as query parameters.
The links on the webpage returned from this endpoint have the "data-test" attribute to make them easier to query using CSS selectors.
The custom query parameter `schema_version` can be used to control whether a V2 or a V3 attribute response is built. You can also force receiving a V3 attribute response by using the client id `dsds98cxsdas`. This client has been set up to behave in the same way as a client registered to receive a V3 response would behave.
For the openid (Authentication/SSO) scope the returned authorization code can be exchanged for access and id tokens however these cannot be used with the attributes endpoint as the person has no verified attributes.
This scope results in personal data: name and dob
This scope results in the persons address fields. Given the very varible structure of addresses all of the fields are optional. An exhaustive list is:
This returns the users email.
This returns the users mobile number. It may have a country code, (e.g. +31, +44), and no spaces
The authorization code can be exchanged for an access and refresh token. The client assertion is a JWT signed by the JWT keypair provided with this mock. In production this would be produced by yourselves.
The access_token and id_token are signed by the mock service, by its private JWT keypair. This should be verified by yourselves using the provided public part of the mock service JWT below. In production this is available from the discovery endpoint.
The access token can now be used to access verified attributes of the person selected earlier. In addition to this, you must also provide another client assertion. That is, a JWT signed by the JWT keypair provided with this mock.
Once the JWT is decoded:
A JWT token is returned that should be verified by the public key provided. Once decoded, will contain the verified attributes of the person, or a failure message if they failed identity verification.
To be used to sign your JWT tokens to produce client assertions to interact with the mock service, note that this is a keypair, so contains both the public and private parts. In production, you will produce this yourself:
To be used to verify signed responses from the mock service. In production, this will be found at the discovery endpoint: