Architectural Design - REST API to Support Facebook Login made by mobile application

Question

I am trying to develop a REST API to support various mobile clients (iOS and Android apps). These applications will allow the user to log in using the facebook login along with our own email authentication. You can refer to the diagram below to understand my design.

There are two levels of authorization:

The first is the “Client (or Application) Authorization”, which uses OAuth2. Therefore, when a user installs our application on a mobile device and launches the application, the very first thing the application does is “Client (App) Authorization”, as shown in the diagram above (1st image). And the server sends back the long-lived access_token client to use for all subsequent calls. Here is my question:

Q1) You can see that the client sends client_key and client_secret , and I store them in the client_info table. Should this secret be in plain text or should it be in decryt-mode format? If I encrypt it, I still need to save the encryption key somewhere on my system. So how will it be safe? Also, in every call decryption will be overhead.

Q2) Is it possible to cache access_token for a client in text format in redis and use this cache first?

Q3) To be more secure, I ask clients to send appsecret_proof to make sure that access_token, they are sent, belongs only to this client. It uses the same concept as Facebook https://developers.facebook.com/docs/graph-api/securing-requests#appsecret_proof . And this is hash_hmac('sha256', access_token, client_secret)

Q4) We will only have our own mobile application (each for iOS and Android), and not providing a third-party user with our API for developing other applications. This means that our client_info table will have only two rows, one for each type of application. Is it okay that in the application code we save client_key and client_secret hardcoded? If so, then in the future, when we must invalidate and use the new secret, how can we achieve replacement of this information?

Q5) Since these are our own applications for several years, several access_token will be created against the same client_key and client_secret . To save them all, it is recommended that you store client_key as a key and array of all access_tokens as a value in redis. In the future, when we open our third-party API, can this redis repository design still scale?

==================

Later, the user decides to perform some actions in my application, for which we need a user to enter his account. For this user, click on facebook login. My application receives facebook access_token and fb user id from facebook and transfers this information to the API server (as shown in the 2nd diagram). The API server accepts this token and calls the facebook API to check its access_token . After checking the token, the server uses some metadata associated with this user, along with the FB access token, to create its own user_access_token , say utoken . And pass that utoken back to the client to pass it on all subsequent user API calls. Here are my questions:

Q1) Is it possible to save the utoken table in the database, user_token . Should this utoken be in plain text or should it be in decryt-mode format? If I encrypt it, I still need to save the encryption key somewhere on my system. So how will it be safe? Also, in every call decryption will be overhead.

Q2) In each user API call, do I have to call facebook every time to check if facebook access_token is still relevant? I believe that I should not, because it will not give me anything. Please note: Facebook is used ONLY to login to facebook.

Q3) What information should I encrypt to generate utoken ? I am thinking of having a hash or an associative array of email , user id , role and facebook token users, and then serialize this data structure and finally encrypt it. Do you think this will be good enough. I understand it at my request, but as a standard or common application, are they good enough? Or is there any best practice?

Q4) Should the client store utoken in its cookie / cache? Isn't that scary?

Q5) Note that a user may have several devices that are logged on with the same user credentials. This means that in the user_token table we will need to store several utokens for those sessions that are logged in, while all of them will belong to the same user. Does this sound right?

Constructive suggestion somewhat familiar to my REST API for a website using Facebook for authentication

Answer 1

Q1.1: No !. Customer credentials are not intended to be used in this way. If your client is a single-page or mobile application, you will have to store the credentials of your client in an insecure environment - the user machine. You must use OAuth Implicit flow

Q1.2: Assuming the token is short-lived, the problem is not cached. The key of OAuth, in addition to relying on another application to authenticate your users, is that you effectively replace the credentials of users or applications that are durable with a short token. Therefore, if someone gets access to the token, at least their access to the system will be limited in time.

Q1.3: read the documentation on facebook:

Graphic API calls can be made from clients or from your server on behalf of clients. Calls from the server can be better protected by adding a parameter called appsecret_proof.

It states that appsecret_proof used for calls from the server on behalf of the user. Here it comes to Q1.1. If you save your client_secret in your user device, they can generate appsecret_proof .

Q1.4: Again, no! You should read the OAuth Specification well and understand the different types of streams and when to use them. Also keep in mind that if you provide an API for your application, the API is publicly available to anyone who will abuse it. The only difference is that it is not documented. The same thing will happen with the web application. Once it's on the Internet, I can write a scraper and offend the web application. This is completely normal, just keep in mind that anything on the Internet is not private, it is simply undocumented.

Q1.5: Again, tokens should be short. If their lifespan is the same for the credentials that live until the user changes them, then the tokens will lose their purpose.

Q2.1: You must save this token. The ReST architecture uses a client cache limit.

Q2.2: I do not think so. Facebook simply tells you that the user who received this token has an identity (e.g. email) that you can associate with the user on your system. Once you learn about this association, you should not really care about the Facebook token, but rather call the Facebook API. But you say you use it only for entry.

Q2.3: It seems nice, but check the Oauth Specification again, as you seem to be building an implicit stream and using JWT tokens. According to what you want to keep in your token, it seems wonderful.

Q2.4: JWT tokens must be cached by the client. It's okay because they are opaque to the client because they are encrypted. The client sends a JWT token with each request, and the API server decrypts the token using the private key (which was never shown outside the server) and can verify the identity of the user.

Q2.5: Remember short tokens. Tokens must end !.