Login from a mobile app

In this flow, the user logs in to the merchant's app with MobilePay or Vipps. The flow starts with a browser for the initial auth request, and after authentication in the Vipps/MobilePay app, the user is redirected directly back to the merchant app.

Overview

The app-to-app flow provides authentication where:

1. The user initiates login from the merchant app
2. A browser opens for the initial auth request
3. The Vipps/MobilePay app opens for authentication
4. The user provides consent within the Vipps/MobilePay app
5. The user is redirected directly back to the merchant app

The process

App-to-App Flow

Integration

The merchant must specify the app URI where the user will be returned after completing the authentication in the Vipps/MobilePay app.

This flow is enabled by adding the requested_flow=app_to_app_v2 parameter to the Authorize request.

PKCE Required

This OIDC flow requires PKCE (Proof Key for Code Exchange) for enhanced security. PKCE is an OAuth 2.0 security extension that prevents authorization code interception attacks.

• PKCE Standard: RFC 7636
• Learn more: Auth0 PKCE Guide

info

For app URIs, we recommend using universal links (Apple)/asset links (Android) instead of custom URL schemes for better security.

The redirect_uri should be a URI that makes the device switch back to the merchant's app after the Vipps/MobilePay app portion of the flow is complete (example: https://example.com/app/callback).

This URI must be added to the sales unit on the portal, portal.vippsmobilepay.com. For help, see Portal: How to set up login on your sales unit.

Important

URIs specified in portal.vippsmobilepay.com must be exactly the same as used in the API calls. Be extra careful with trailing / and URL-encoded entities.

Sequence diagram

A typical flow/implementation might look like this:

App-to-App Flow Sequence

The dotted lines in this diagram are handled by us (or the user), while the filled lines need to be implemented by the merchant.

1. The merchant's backend generates an OpenID authentication flow authorization URI with requested_flow=app_to_app_v2.
2. The URI is communicated to the merchant's app in the API response.
3. The merchant's app uses the URI to initiate Login in an external browser that is opened within the app.
4. Login will open the Vipps/MobilePay app for authentication.
5. The user authenticates and provides consent within the Vipps/MobilePay app.
6. Vipps/MobilePay app opens the deep link redirect_uri with authentication tokens.
7. Merchant app receives the tokens and exchanges them for user information.
8. Merchant backend fetches the user information using the received tokens.
9. Login provides user information.
10. Merchant backend delivers user information to merchant app.

Example authorize request URL

.../oauth2/auth?requested_flow=app_to_app_v2&scope=<scopes>&response_type=code&redirect_uri=https://example.com/app-callback&code_challenge_method=S256&state=<state>&nonce=<nonce>&client_id=<clientid>&code_challenge=<challenge>

Example callback from app

Example success callback from app (step 6):

https://example.com/app-callback?state=218gz18yveu1ybajwh2g1h3g&code=<code>&scope=openid

Example error callback from app (step 6):

https://example.com/app-callback?state=218gz18yveu1ybajwh2g1h3g&error=unknown_error

Implementation considerations

Security

• Use universal links (Apple)/asset links (Android) for better security
• Validate the state parameter to prevent CSRF attacks

User experience

• Provide clear messaging about the authentication process
• Handle error cases gracefully

Platform-specific considerations

• iOS: Use ASWebAuthenticationSession or SFSafariViewController for the initial browser interaction
• Android: Use Chrome Custom Tabs for the initial browser interaction
• Ensure proper deep link handling in your app for the callback

Migration from legacy flow

If you're currently using the legacy app-to-app flow, you can migrate to this flow by:

1. Updating your authorize request to use requested_flow=app_to_app_v2
2. Ensuring your implementation uses PKCE (Proof Key for Code Exchange)
3. Simplifying your callback handling by cleaning up any app_callback_uri handling which is no longer used.