REST API Authorization type

Question

I have read a lot of about the way to provide acces to a REST API and I still cannot come with a decision what to use.

In my case I am writing a REST API that will be used by the users of the mobile application(android&iOS), thus I do not provide or require access from third parties and this makes me think that I don't have to use OAuth. However I have considerations about how to provide access of one user's account from multiple devices and how to provide offline access.

Another consideration I have is how should I restrict the API access, for example if using API Tokens what are the best practices for expiration and renewal of the tokens?

Answer 1

You have several topics in your question:

• What are the benefits of OAuth2 for an internal API exposed on the Internet?
• How should I manage tokens?
• How can a user gain access via multiple devices?
• How can a user have offline access?

I discuss these questions below.

Oauth2

OAuth2 offers a standardized protocol for several authentication schemes of varying complexity. One of the most complex use cases is the 'Authorization Code Grant' flow which allows a resource owner (user) to grant specific access to a client application via an intermediary, the Authorization server. This is what happens when you 'login using google'. The advantage of using OAuth2 over a homebrew solution is that the protocol is clear to all parties and less likely to contain fundamental flaws. A drawback can be that the protocol is not that flexible so some custom scenario's might be hard to support within the boundaries of OAuth2. If you don't have the immediate need for any of the typical OAuth2 scenario's (or a stakeholder demanding use of OAuth2) then I suggest not starting off with it, but to implement a simple token scheme yourself.

Managing tokens

The most common way to manage API access is by using tokens. A token is generated when the user logs in, typically with username and password over HTTPS. The token is persisted on the server and must be supplied by the app in each request. This is similar to the session ID used in web applications which is automatically generated and handled in-memory by the application container on the server and passed via a cookie or request parameter. An API token is typically handled by the security layer of the application itself, persisted in the database and passed via the 'Authorization' header.

A token should have an expiration date. One should decide on the best interval for this and whether token renewal is automatic (each time the user accesses the API) or explicit (force the user to re-enter credentials after expiration). This depends on the type of application and the level of security required. Tokens can also be revoked manually on the server.

Multiple devices

Each token can be associated with a specific user and device to allow access on multiple devices. This means each device must be uniquely identified, typically with the IMEI code. This makes it easy to revoke all tokens for a specific device or user at once.

Offline access

The typical way to offer offline access is to cache relevant data on the device. For example the Google Maps app allows you to make specific regions of the map available offline. To avoid (too) stale data you could keep track of the token's expiration date and invalidate the cached data after this date. An issue to be aware of is the handling of offline edits by the user. These edits have to be processed when the device comes online again. When simultaneous edits on the same data are encountered a strategy is needed to resolve the conflict, e.g.:

• one edit overrides the other depending on the type of edit or the role of the user
• the last edit is ignored or offered for resolution to the last editor
• some types of edits might be 'merged' automatically
• etc.

Another nice and simple strategy is to disallow all edits whilst offline.

Answer 2

There are 2 things you want to protect / authenticate

• That the client app is authorized to use the service
• That the user is authorized to access personal data

App authentication

A mobile application is an untrusted client. Even if you gave nobody access to the app source you must expect that any kind of authorization secret or mechanism is unsafe and can come from a hacked app or other malicious tool that emulates the behaviour of your apps.

For authenticating the app, all you can do is to have a client id, but not a client secret. E.g.

http://service.com/rest?client_id=android

Reply method(String client_id) {
   if (!client_id in ["andoid", "ios"])
       return Unauthorized();
}

You can change that schema to something a little harder to guess but anything you do boils down to the same security level.

User authentication

Protecting user data is crucial and luckily possible. The key difference is that the secret is not statically hardcoded into the app, it is only known to the user.

One "easy" way to authenticate users is to use other accounts they have. Schemas like http://openid.net/connect/faq/ allow you to do exactly that.

You basically delegate the authentication to some other service. and get a (per service) unique user id which you can use in your code as key to all user data. An attacker can not forge this since your server can authenticate that the token is valid by asking another service. Looks roughly like

http://service.com/rest?client_id=android&user_token=aasjkbn9nah9z23&user_auth_service=facebook

Reply method(String client_id, user_token, user_auth_service) {
   if (!client_id in ["andoid", "ios"])
       return Unauthorized();
   authenticated_user_id = user_auth_service.getUserIdOrFail(user_token);
   accessDatabase(authenticated_user_id);
}

An attacker can still use your service from some evil app but there is no way to access accounts he has no access to anyways.

And if you hardcode access tokens into the app, you better don't expire them or make sure to handle that case specifically in the app somehow. There are always users with outdated app versions.