Purpose
We require the OAuth 2.0 state
parameter on all requests to the /authorize
endpoint in order to prevent cross-site request forgery (CSRF). he OAuth 2.0 specification requires that clients protect their redirect URIs against CSRF by sending a value in the authorize request that binds the request to the user-agent's authenticated state. Using the state
parameter is also a countermeasure to several other known attacks as outlined in OAuth 2.0 Threat Model and Security Considerations
The state
can be an arbitrary value. In the future , the state
parameter is used to prevent Cross-Site Request Forgery (CSRF) attacks. In addition to this, because the redirect_uri
parameter is fixed in the production version, the state
can be used to distinguish users.
The same value will be returned to the [REDIRECT_URI] as a state
parameter. For example: if you included parameter state=4cac8f43
in the authorization URI, when the user is redirected to [REDIRECT_URI], the URL would contain that same value in astate
parameter. The value of state
should be unique for each request.
In terms of differentiating merchant, you can do so by state. In the first call, the authorization call, you set a state. MobilePay then returns this state, when you obtain the authorization_code. This way, you can differentiate, if you have more merchants working on the Consent process. Afterwards, it is your responsibility to manage, which tokens belong to which merchants. This is solely a security aspect, that we do not enclose information about this, when you get the refresh_token. But this is also a response for a call, that you initialised yourself, and the response comes instantly. This is why there shouldn't be any confusion.
Identity server will echo back the state value on the token response, this is for round tripping state between client and provider, correlating request and response and CSRF/replay protection.