cancel
Showing results for 
Search instead for 
Did you mean: 

Setup iOS application in SCP Mobile Services using OAuth with Client Credentials

gregcarino
Product and Topic Expert
Product and Topic Expert

Hi Experts,

We have a native iOS application registered in SCP Mobile Services to use OAuth (using Authorization Grant) as the authentication mechanism, as per this setup. The app is working as expected.

Token lifetime is set to infinity.

The iOS application will function as a kiosk that should always be logged-in. However, there is an issue with our corporate IdP that causes the device to be logged off intermittently.

Due to this, we are thinking of setting up the application to use OAuth (using Client Credentials) instead, to bypass the SAML authentication and allow the iOS app to retrieve the access token using client credentials instead.

I would like to ask 2 questions:

1. Is this the correct approach for setting up an always-logged-on iOS application?

2. I have configured an OAuth client (using client credentials) in SCP and can get an access token via postman. If we were to set up our iOS application to use that client, what is the correct configuration that should be set in SCP mobile services (if any), and the iOS application (which I believe has default configuration parameters only for OAuth using Authorization Grant)?

Regards,

Greg

View Entire Topic
former_member190800
Contributor
0 Kudos

I think the question is what is the expected behavior of 'log-off''? OAuth2 has two tokens: ACCESS, and REFRESH. Typically the ACCESS token has a relatively short life-span, while the REFRESH token has a long (or infinite) lifespan.

Both tokens are issued by SCP's identity layer, when the use successfully first authenticates against the configured Trust Provider. This authentication *typically* requires a user interaction, though if you are using MDM to install client certificates to the system keychain, that identity can be used to reduce user-input. Both tokens are stored by the SAP Cloud Platform SDK for iOS, either directly in the application keychain, or in an encrypted file. (We refer to this storage generically as 'SecureStore').

From the perspective of the iOS app, the ACCESS token is retrieved from the SecureStore at runtime, and set as an authorization header for requests to SCP. If it is rejected, the SDK automatically retrieves the REFRESH token from the SecureStore, and issues a new request to SCP to issue a valid ACCESS token, which is then used to complete the request, and stored for future utilization.

So to come back to your question: does the 'log-off' invalidate the REFRESH token? If not, this may not be an issue at all, as the SDK will automatically use the REFRESH token to recover a valid ACCESS token, which can be used going forward. No user interaction is required for this.