OAuth 2.0
Introduction
Neptune OAuth 2.0 Authentication is a feature that enables the use of OAuth 2.0 authentication by using tokens for authentication. This authentication method stands out due to its ability to utilize the configured authentication in your SAP System (similar to the Native Authentication type) while also implementing a Bearer token header authentication that uses access or ID and refresh tokens.
In the Mobile client configuration you can use three different OAuth Flow Providers that you can specify with the correspoding dropdown value.
SAP (SOAUTH2)
This OAuth Flow Provider implements the native OAuth 2.0 PKCE authentication flow. The SAP system itself will be in charge of issuing and maintaing OAuth tokens. You can find all details of this provider in section SAP (SOAUTH2)
SAP Open ID Connect (SOIDC)
This OAuth Flow Provider implements the OpenID Connect authentication flow. The SAP system acts as an OpenID Relying Party (RP) that would trust Bearer tokens that are issued by an external OpenID Provider (OP). The setup of this flow is very simple but requires a recent SAP_BASIS release. You can find all details of this provider in section SAP Open ID Connect (SOIDC)
Mobile Client Configuration
In the Mobile Client, you will find the OAuth 2.0 configuration in the Authentication tab of the detail screen of a Mobile Client.
There you will find the following OAuth Flow independent settings:
Authorize Browser Type (only Mobile Client and not PWA-enabled Launchpad)
This setting allows you to specify which browser type should be used that calls the /authorize URL and presents the user with the login screen of the corresponding IDP. It is recommended to use the Native Browser as this is the most modern way of implementing OAuth authentication flows in mobile applications. However, there can be situations where you might want to use the InAppBrowser.
Create Login Cookies (MYSAPSSO)
This flag is optional but needs to be set if you are using Fiori Standard or other non-Neptune SAP applications like WebDynpro or WebGUI. If enabled, the mobile client will generate a MYSAPSSO cookie and use it for authentication in these non-Neptune scenarios. You need to confirm that parameter login/accept_sso2_ticket has been enabled in transaction RZ11 to allow MYSAPSSO cookie generation.
So for instance you cannot use any underscores in the app ID. The reason for this is that the callback from the native browser to the main Cordova app happens through an app URL scheme. The value for the app URL scheme will be the app ID. If that contains invalid scheme characters the native browser window will stay open and the authorization code cannot be sent back to the main app. Example: When you have an app ID in the mobile client with the value "com.neptune.oauthapp" the final step of the /neptune/oauth/authorize call will be a redirected to the URL com.neptune.oauthapp://code=theAuthorizeCode after successful authentication. This will lead to a redirect to the mobile client. However, if you have an app ID that contains unsupported characters as a URI scheme (for example com.neptune_dev.oauthapp) the redirect would not work. Instead, you would get an error page telling you that the redirect does not work. The native browser window will stay open in that case. |