Lets talk a little about OAuth in Android 12
Tags: android, kotin, mobile, tristan
Published: 2023-11-01 02:03:02

### Table of contents
1. [Introduction](#intro)
2. [Why did everything break?](#break)
3. [Why change? ](#change)

### My app on the Google play store
- [The app](https://play.google.com/store/apps/details?id=elliott.software.clicker)


### Introduction <a name="intro"></a>
- So if you have tried to implement some sort of oAuth authentication by hand(like myself) you may of noticed things start to break when you're targeting a device that has Android 12 and up.

### What happened ? <a name="break"></a>
- Well as the documentation states, [HERE](https://developer.android.com/about/versions/12/behavior-changes-all#web-intent-resolution): `Starting in Android 12 (API level 31), a generic web intent resolves to an activity in your app only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead.`

- long story short, you need special code specifically for android 12 and up

### Why change at all ? <a name="change"></a>
- After reading the [Internet Engineering Task Force's specifications on OAuth 2.0 for Native Apps](https://datatracker.ietf.org/doc/html/rfc8252) I believe Google did this to strengthen apps that use the [OAuth Implicit Grant Authorization Flow](https://datatracker.ietf.org/doc/html/rfc8252#section-8.2) against the [authorization code interception attack](https://datatracker.ietf.org/doc/html/rfc7636#section-1). Apps that use any kind of Implicit Grant Authorization Flow are susceptible to this attack. While I could go on a lengthy explication about this attack, I will let a picture do the explaining: 

![authorization code interception attack diagram](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ix6bsirbueta6obbeyh.png)


- In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter-application communication within the client's operating system(done through implicit intents on Android).

- The malicious app can then use that authorization code to get a token from the authorization server and impersonate the user. 

- Google makes this harder by, as the [docs state](https://developer.android.com/training/app-links/verify-android-applinks#request-user-associate-app-with-domain): 

`On a given device, only one app at a time can be associated with a particular domain. If another app is already verified for the domain, the user must first disassociate that other app with the domain before they can associate your app with the domain.`



### How do I implement this ?
- Well, as it clique as it may sound, [READ THE DOCS!!!!](https://developer.android.com/training/app-links/verify-android-applinks)!!!! But know I only say this because it is very situational and it really depends on if your app has a server backend or is completely a client app.


### Conclusion 

- Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on [Twitter](https://twitter.com/AndroidTristan).