The 1st step is forming an authorization request with the appropriate URI parameters at the authorization endpoint
- You can find detailed information about this request in the OpenID Connect specification here
- Specification of parameters are found here
- Sandbox Authorization Endpoint DK:
- Sandbox Authorization Endpoint FI:
- Production Authorization Endpoint DK:
- Production Authorization Endpoint FI:
- The OpenID Connect protocol requires the use of multiple endpoints for authenticating users, and for requesting resources including tokens.
- To simplify implementations and increase simplicity, OIDC allows the use of a "Discovery document" OpenID Connect Discovery, where an OpenID server publishes its metadata at a well-known URL, typically
- This URL returns a JSON listing of the OpenID/OAuth endpoints, supported scopes and claims, public keys used to sign the tokens, and other details. The clients can use this information to construct a request to the OpenID server. The field names and values are defined in the OpenID Connect Discovery Specification.
Here is an example of data returned:
OpenID Connect Discovery
|Environment||Link to configuration data|
Before a client can access a protected resource, it must first obtain an authorization grant from the resource owner, and then exchange the authorization grant for an access token. You should retrieve the base URI from the Discovery document using the authorization endpoint. The next step is forming an authorization request with the appropriate URI parameters at the authorization endpoint, which can be done by
- HTTP GET -If you're using it, the request parameters are added to the HTTP request entity-body using the application/x-www-form-urlencoded. Read more here
Explanation of mandatory parameters
OAuth 2.0 Response Type value that determines the authorization processing flow to be used, including what parameters are returned from the endpoints used.
the client_id that you received by zip file. This is not the same as the MerchantID or the e-mail log-in to https://sandprod-admin.mobilepay.dk
|The client-id given in the zip file||Yes|
the HTTPS endpoint on your server, that will receive the response from MobilePay. It needs to be whitelisted by MobilePay.
|Customer redirect uri as registered by firstname.lastname@example.org||Yes|
A space list of scopes. For this flow, the full list of possible scopes is
subscriptions invoice openid transactionreporting offline_access
State is used to maintain state between the request and the callback. You generate a new value for each request, and we return it in response for you to validate.
|Unique random value||Yes|
Dcoumentation can be found here. A challenge for PKCE. The challenge is verified in the access token request, it will be used in combination with the next call.
|The value should be a SHA 256 hash of a crypto random byte array.||Yes|
String value used to associate a client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the authentication request to the ID Token. Sufficient entropy must be present in the nonce values used to prevent attackers from guessing values. Should be a new random value for each request. We invalid a nonce once our back-end has received it, so next time we get a request with the same nonce, we then reject it.
|Unique random value||Yes|
A string value equal to the VAT number for the merchant. This is used to identify which merchant that should be given consent to if a user has multiple merchants assigned. We support FI and DK vat numbers. The vat number consists of country prefix (either FI or DK) and 8 digits.
|Country prefix + VAT number of merchant||Yes|
By using the value, that you used when creating the
When the Merchant is logged in, the MobilePay Portal presents the Merchant with a consent screen, that describes the information that the Merchant is granting to. For example, when the user wants to have MobilePay Subscriptions, the consent screen asks to give access to Subscriptions. The request access to this information using the scope parameter, which you include in the authorize request. You can also use scopes to request access to other MobilePay API's. When the Merchant clicks yes (gives consent), the Merchant is redirected back to the integrators website/environment).
Integrator has been provided with a test merchant to our MobilePay Portal - Sandbox. Integrator should use the e-mail and password provided in the invitational e-mail to log-on to it.
Once the user authenticates successfully, the application will be redirected to the
redirect_uri, with a
code as part of the URL:
https://YOUR_APP/callback?code=BPPLN3Z4qCTvSNOy. You can exchange this code with an Access Token using the token endpoint
You might see this page when trying to obtain an
authorization_code. If you see this page, it is most often due to an invalid request. The request is missing a required parameter, includes an invalid parameter value or a redirect_uri, that hasn't been whitelisted. MobilePay does not provide additional information, used to assist the client developer with additional information about the error, in order to mitigate against cross-site request forgery. Ensure that all required parameters are present and valid.
OpenID Connect - Glossary
Step 2 - Get Code
The purpose of Step 2 is to have Authorization Code returned to your Redirect URI. You need to wait for the response by listening on the redirect URI and get the Authorization Code.