OAuth 2.0 for Mobile and Desktop Apps

Overview of the OAuth 2.0

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 provides simple means to develop native apps such as web applications, mobile applications & desktop applications to third-party developers. OAuth 2.0 requires clients to be registered their app with service first. When registering a new app, you will add a few basic information for your application such as application name, logo, client website, etc. Additionally, you must specify a redirect URI, which makes sure the service will only send authorization code to registered URI and add an additional level of security to authentication flow. On registering the application, you will receive a client id & optionally client secret. The client id is considered a public key and it will be used to generate login URL. Redirect URI only limits the chance of remote attacks; Other applications installed on the same native device can still intercept authorization code. Unlike web services mobiles application runs on a native device so they cannot maintain the confidentiality of client secret, so it's suggestive to not use client secret for unsecured apps, rather use additional dynamic generated secret from the application end (Known as PKCE).

Authorization

For Authorization client mobile app redirects it to service native app or service web page for user to login.

Since mobile apps are considered less secure to store client credentials, Client mobile must implement additional authentication flow using PKCE extension.

Using web browser

Mobile applications redirect to a web browser for login especially when there is no native application provided by authentication service. You should either launch the native mobile browser or use iOS "SafariViewController" to launch an embedded browser in your application.

Note: It’s not suggestive to use embedded web view in the native application as user can’t see address bar so doesn’t have any idea on which service user is entering credentials.

In iOS  SafariViewController provides a way to launch a browser in native app with an address bar visible.

URL format:

• SERVICE_URL – URL of OAuth service.
• response_type=code - indicates that your application expects to receive an authorization code.
• client_id=CLIENT_ID - client ID you received when you created the application on service.
• redirect_uri=REDIRECT_URI - indicates the URI on which authorization code needs to return after the authorization process is completed.
• scope=email - One or more scope values indicate which parts of the user's account client app wish to access.
• state=abcxzy - A random string generated from your application, which you'll verify later, this will make sure the authorization code is not intercepted.
• code_challenge=XXXXXXX - Base64 encoded string of the sha256 hash of the code verifier (explained below).
• code_challenge_method=S256 - Hashing method used to compute the challenge, in our example, sha256.

Code Verifier is a random string generated from your application (usually of length between 50-128 characters), then uses the same string to create hash & finally use generated hash to URL-safe Base64 string. This Base64 string is called a code challenge.

Using Native app

If a native service application is installed on mobile, then redirect the user to a custom URI scheme registered from the service application. Consider you are implementing Facebook OAuth flow & mobile has the Facebook app installed on the device, then the app just has to redirect the user to below URI

Where fbauth2 is a custom redirect scheme for the Facebook app. When using a service native app for authentication you must add a custom URL scheme for your mobile application too so native service can send back authentication code to your app. 

When your mobile app executes these URL requests it will ask for user credentials to access the service & on successful login, it will ask the user for permission to share specific info of the account with a client app.

Recommendation: Introduction To Xamarin For Beginners

Getting Access token

After the user is allowed to access information, the service will redirect the authentication code and state it on REDIRECT_URI.

A mobile app will verify the state received to confirm the authorization code is not intercepted. If the state code verifies with the initial request from the app, we can use the received authorization code to get the access token.

• grant_type=authorization_code - Grant type in this example is authorization_code. There are others grant types too like password & client_credentials 
• code=AUTH_CODE_HERE - code you received in the query string from the authorization request.
• redirect_uri=REDIRECT_URI - indicates the URI on which authorization code needs to return after the authorization process is completed.
• client_id=CLIENT_ID - client ID you received when you created the application on service.
• code_verifier=CODE_VERIFIER - Random string you generated at the beginning.

The OAuth service will create a hash of code verifiers & try to match it with the code challenge you sent in the request, and issue the access token only if both matched. This process will ensure even if someone has intercepted the authorization code, they will unable to use it to get an access token since they won't have the secret.

Other grant types

Password

OAuth 2.0 also provide access tokens directly using the user’s credentials. Since this type of grand directly works with user credentials it's mainly used in apps that are created by the authentication service itself.   

• grant_type=password - Grant type in this example is password.
• username=USERNAME - User's username for the application.
• password=PASSWORD - User's password for the application.
• client_id=CLIENT_ID - client ID you received when you created the application on service.

OAuth service responds with an access token in the same format as the other grant types.

Application Access

Some of the applications may need to only push user preference of usage, activities without any user login for which app needs to authenticate to service first; In such cases, we’ll use client_credentials grant type.