The 7 scenarios my authentication system has to deal with in Android with Kotlin
Tags: mobile, android, kotlin, tristan
Published: 2024-01-29 11:18:42

### Table of contents
1. [What is this about?](#what)
2. [No Network](#no)
3. [Network reconnect](#reconnect)
4. [Wifi vs Cellular data](#wifi)
5. [No Authentication token](#token)
6. [Setting new Authentication token](#set)
7. [401 response](#response)
8. [Generic failed response](#generic)
9. [Any scenarios I am missing?](#missing)



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


### What is this about ? <a name="what"></a>
- My application does authentication through [Twitch's OAuth2.0 authentication backend](https://dev.twitch.tv/docs/authentication/) and these are the following scenarios that my application has to deal with. These situations might seem obvious to most people. However, There are not a lot of resources that talk about what types of things a authentication system should handle. So this blog post is a general guide on situations you should plan for.



### 1) No Network <a name="no"></a>
- All of your requests, not just the authentication ones, should be able to handle the scenario when the device is not connected to a network. To handle this situation, you should notify your user of the fact that they are not connected to a network and wait quietly for a network to connect

### 2) Network reconnect <a name="reconnect"></a>
- When a network reconnects to your application, you should rerun the previous method and or refresh all the data necessary to the user's experience.

### 3) Wifi vs Cellular data <a name="wifi"></a>
- If our application switches from wifi to cellular data, we should be courteous and notify our users of such interaction. This way our users can decide if they want to continue with cellular data or stop using our app and wait for wifi availability 

### 4) No Authentication token <a name="token"></a>
- A Client application(mobile apps are considered client apps) will do authentication with some sort of token. If there is not token stored locally on the device, you should notify you user they need to authenticate with the backend. Usually this is done with a `Login with ....` button

### 5) Setting new Authentication token <a name="set"></a>
- Once the user on your application is issued a new authentication token, you should refresh all of the data stored locally and showed to your user. As a new authentication token could mean a totally new user

### 6) 401 response <a name="response"></a>
- When a request returns the 401 Unauthorized response. Which is a  status code indicating that the client request has not been completed because it lacks valid authentication credentials. Your application should make a automatic request to refresh your authentication token and try the request again.

### 7) Generic failed response <a name="generic"></a>
- Mobile user are mobile. Meaning they will not always have the best connection and requests can fail for any number of reasons. So if the request fails for a generic reason, ie, not 401 or network failure. You should automatically retry the request before telling the user that their request has failed.

### Any scenarios I am missing? <a name="missing"></a>
- If there are any other scenarios I am missing please tell me in the comments below


### 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).