How to manage OAuth flow in mobile application with server-CodePudding

The

In order to avoid the client secret hardcoding in my mobile client, could the following code flow based on the image work and be safe to connect to Strava, Garmin, Polar....?

Strava connection example:

MOBILE CLIENT

Mobile public Client Calls my Rest API to get as a result the URI of Strava Authorization server login with needed params such as: callback, redirect_uri, client_it, etc.

Mobile client Catches the Rest API GET response URI.

Mobile client launches a user agent (Chrome custom tab) and listen to the callback.

USER AGENT

The login prompt to strava is shown to the resource owner.

The resource owner inserts credentials and pushes authorize.

Callback is launched

MOBILE CLIENT

When my client detects the callback, return to client and stract the code from the callback uri.

Send that code to my REST API with a post. (https://myrestapi with the code in the body)

REST API CLIENT

Now, the client is my REST API, as it is going to be the one that calls the authorization server with the code obtained by the mobile client. The client will take that code and with the client secret hardcoded in it will call to the Authorization server. With this approach, the client secret is no more in the mobile client, so it is confidential.

The authorization server returns the tokens and I store them in a database.

THE PROCESS

Takes those tokens from my database and make calls to the resource servers of strava to get the activities. Then parses those activities to my model and stores them into the database.

Is this second approach a good way to handle the client secrets in order to avoid making them public? Or I am doing something wrong? Whatr flow could I follow to do it in the right way? I am really stuck with this case, and as I am new to OAuth world I am overwhelmed with all the information I have read.

CodePudding user response：

From what I understand, the main concern here is, you want to avoid hardcoding of client secret.
I am taking keycloak as an example for the authorization server, but this would be same in other authorization server as well since the implementation have to follow the standards
In the authrization servers there are two types of client's one is the
1.Confidential client - These are the one's that require both client-id and client-secret to be passed in your Rest api call

The CURL would be like this, client secret required

curl --location --request POST 'http://localhost:8080/auth/realms/testrealm/protocol/openid-connect/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=authorization_code' \ --data-urlencode 'client_id=confidentialclient' \ --data-urlencode 'client_secret=<CLIENT_SECRET_VALUE>' \ --data-urlencode 'code=<AUTHORIZATION_CODE_VALUE>' \ --data-urlencode 'redirect_uri=http://localhost:8080/callback' \ --data-urlencode 'code_verifier=<CODE_VERIFIER_PKCE>'

2.Public Client - If you create clients with this option you won't have to pass the client secret. Only client-id is sufficient while making the API calls.

For public clients you won't need to pass client secret, one less problem to worry about

curl --location --request POST 'http://localhost:8080/auth/realms/testrealm/protocol/openid-connect/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=authorization_code' \ --data-urlencode 'client_id=publiclcient' \ --data-urlencode 'code=<AUTHORIZATION_CODE_VALUE>' \ --data-urlencode 'redirect_uri=http://localhost:8080/callback' \ --data-urlencode 'code_verifier=<CODE_VERIFIER_PKCE>'

These options would be and should be available in most of the standard authorization servers.

CodePudding user response：

The second approach which you presented is a valid one to implement an OAuth flow. Your backend can act as the confidential client you need, and you can safely obtain tokens from Authorization Servers. This pattern is sometimes referred to as Backand-For-Frontend (though this name is a bit overloaded nowadays). At Curity we described something similar, which we call the Token Handler Pattern. The premise is similar, but our main target are Single Page Applications which can leverage cookies to manage sessions.

Of course the thing you need then is to create a secure session between your backend and the mobile app. In a browser app you would use just use plain old sessions with cookies. You have to make sure that noone can impersonate a user of your app when calling your backend.

Another thing you can explore is whether Stravia supports Dynamic Client Registration standard. Using DCR you can register each instance of your mobile app as a separate client. Then each of those clients receives their own client ID and secret. You then don't have to worry about the secret being stolen.

You can also reach out to Stravia and ask them why they don't support public clients with PKCE and whether they plan to do it. PKCE is an important security OAuth standard and companies should seek to support it.