Search code examples
web-servicesauthenticationsdktokenmbaas

Significance of App key and App Secret in MBaaS world


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.


Solution

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