0

I am building mobile backend services. I was wondering, Imagine a service like Authentication Service provided App key ad App secret to people who buy a bunch of services ( logically called an app ).

Lets assume there are services X , Y , Z , etc., and also a AuthService.

Assuming there is no concept of a "User" in the app, I figured I can restrict API access of a service by using app key and app secret.

But,

Since I can't validate (appkey , appsecret) locally because there as as good as (username , password) , I have to make an AuthService service-call to find out if the API call is valid. But this will affect performance as every call to a service X is actually two service calls.

My Question: Are Apps validated at all, usually? Why use appkey and appsecret, at all? Why not have an "app token" coming from the app which is self sufficient and I don't have to make an AuthService call. You could always use Https and avoid man in the middle, and have the app token stored securely by the SDK.

I heard about solutions like caching the app info(app-token) in services like X , Y , Z ... and verifying locally. But once you get hold of my app key and secret , you can party irrespective of where i store it, also caching would be redundant in individual services. You will end up storing the authorization information also, in the cache which can potentially change quickly. Cache Invalidation might be a problem. ?

Please help, Thanks in advance.

Karthik Avjs
  • 77
  • 2
  • 7

2 Answers2

0

I will answer your questions one after the other mostly not in sequence

1. Caching the appid and appkey

Here appKey is like a password and appId is a username. You won't save a password as it is in database. I will be hashed using salt and then will be saved into database. As it is know that hashing is one way, even if hacker got access to the database he cannot get the password of the user.

2.Calling Auth server each and every time

Rather than calling the auth server each and every time, generated a time bound token which will be used for the time it specified and once the token expires you can generate a new token or increase the validity of existing token. you can cache this token rather than caching the appKey.

NOTE : If given enough resources and enough time any password can be breakable. the cost of resource and time might be very huge

kishore
  • 1,658
  • 7
  • 24
  • 33
  • Thanks for the reply. I seem to have not mentioned my question clearly. The app info I mean to cache, I was referring to the app token, not the app key. So as I take it, You agree to go with app token . The second problem is obviously Caching it in the service vs sending it back to device and (use SDK ) to store it securely. Token refresh / increase validity of existing token should be the device's problem as it could loose connectivity (potentially for a long time). Why would the service have to take care of it all the while? – Karthik Avjs Feb 20 '14 at 10:49
  • while the sdk is returning the token for some data, the service should validate it to make sure this is actual app making the request – kishore Feb 20 '14 at 13:36
0

The described scenario looks like a classic case for OAuth 2.0 authorisation with self-contained bearer access tokens.

The clients will be authenticated and issued an access token at the OAuth 2.0 authorisation and / or token endpoint. The access token can be represented by a signed JWT which encodes the permission scope and validity time-frame in a JSON object that is signed with the OAuth 2.0 server's RSA key. The X, Y, and Z services only need to check the signature upon receiving the JWT access token in order to clear the request. This will save you the network call to the auth service and an RSA signature check can be done in about 100 microseconds which is a lot less than an HTTP request (in the order of tens or more milliseconds).

Community
  • 1
  • 1
Vladimir Dzhuvinov
  • 772
  • 1
  • 6
  • 13