This post and the following three posts are all about accounts in android. My complete code for account authentication is also available as an open-source code in Github.

What is that?

AccountManager is the built-in class for account management in android, where account is one of the types you see in Settings → Accounts:

The above screenshot shows two sample account types, i.e. DigiGene and Google. Each account type can have multiple instances called account names:

Adding accounts for an account type is possible either through ‘Add Account’ in the first image above — which is the indirect way of creating account– or directly using the app that has made this account type available.

Ok… what’s that good for?

• First is to store multiple account names with different levels of access to the app’s features under a single account type. For example, in a video streaming app, one may have two account names: one with demo access to a limited number of videos and the other with full-month access to all videos. This is not the main reason for using Accounts, however, since you can easily manage that in your app without the need for this fancy-looking Accounts thing… .
• The other advantage of using Accounts is to get rid of the traditional authorization with username and password each time an authorized feature is requested by the user, because the authentication takes place in the background and the user is asked for their password only in certain condition, which I will get to it later.
• Using the Accounts feature in android also removes the need for defining one’s own account type. You have probably come across the apps using Google accounts for authorization, which saves the hassle of making a new account and remembering its credentials for the user.
• Accounts can be added independently through Settings → Accounts
• Cross-platform user authorization can be easily managed using Accounts. For example, the client can access protected material at the same time in their android device and PC without the need for recurrent logins.
• From the security point of view, using the same password in every request to the server allows for possible eavesdropping in non-secure connections. Password encryption is not sufficient here to prevent password theft.
• Finally, an important reason for using the Accounts feature in android is to separate the two parties involved in any business dependent on Accounts, so called authenticator and resource owner, without compromising the client (user)’s credentials. The terms may seem rather vague, but don’t give up until you read the following paragraph … 😉

Let me elaborate on the latter above with an example of a video streaming app. Company A is the holder of a video streaming business in contract with Company B to provide its certain members with premium streaming services. Company B employs a username and password method for recognizing its user. For Company A to recognize the premium members of B, one way would be to get the list of them from B and utilize similar username/password matching mechanism. This way, the authenticator and resource owner are the same (Company A). Apart from the users obligation to remember a second password, it is very likely that they set the same password as their Company B’s profile for using the services from A. This is obviously not favorable.

To allay the above shortcomings, OAuth was introduced. As an open standard for authorization, in the example above, OAuth demands that the authorization be done by Company B (authenticator) by issuing some token called Access Token for the eligible users (third party) and then providing Company A (resource owner) with the token. So no token means no eligibility. In the following, I’m going to shed light on some more details of this, so stay tuned! 🙂

How OAuth works then … ?

The latest of OAuth standard, OAuth 2.0, works as follows:

When the user tries to access a protected service from the resource owner for the first time, the resource owner refers them to the authenticator to submit their username and password for getting the required tokens. If the credentials were correct and the user were eligible for the service, the authenticator would issue two tokens, namely Access Token and Refresh Token, which are then saved in the client. This is what I call SIGN-UP. Access token is then used in the rest of the requests to the authorization server, so-called SIGN-IN. If the access token is valid, access to the protected material is granted in the result from the authorization server. If unauthorized, the access token is expired. This expiration is due to the fact that using a constant access token for an unlimited time results in a security vulnerability owing to the possible eavesdropping described above. The refresh token is thus used in another request to get a new access token. The refresh token itself is not constant in time either and expires; nevertheless, the period of time before the refresh token expires is much longer than access token. Expiration time for access token is usually in the order of a few days while refresh token expires once or twice a year, unless user changes their password or is denied access. In the latter case, both access and refresh tokens expire.

Once refresh token is expired, user is led to the SIGN-UP page to enter password to get another access and refresh token from the authorization server.

Table below summarizes the process.

Authentication procedure name	Input	Result
REGISTRATION	account name, account type, optional data	whether account name is available
SIGN-UP	account name, account type, password, optional data	access token, refresh token
SIGN-IN	account name, account type, access token, optional data	whether access token is valid or no

This concludes this part. In the next part, I will deal with ‘AccountManager’ in android to show how the above is implemented.

Please feel free to share your feedback.