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
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 a
state 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.