Architecture Design - REST API to support Facebook Login done by Mobile app -

i trying design rest apis support various mobile clients (ios , android apps). these apps let user login using facebook login along our own email authentication. can refer diagram below understand design

there 2 levels of authorization take place:

first 1 "client (or app) authorization" uses oauth2. when user install our app on mobile device, , starts app, first thing, app makes "client (app) authorization" shown in above diagram (1st image). , server sends long-lived access_token client use subsequent calls. here question are:

q1) can see client sending client_key , client_secret , storing them in client_info table. should secret in plain text or should in decryt-able format? if encrypt it, still need keep encryption key somewhere in system. how make secure? in every call, decryption overhead.

q2) ok cache access_token client in plain text format in redis , use cache first?

q3) in order safe, asking clients send appsecret_proof make sure access_token, sending belongs client only. uses same concept facebook https://developers.facebook.com/docs/graph-api/securing-requests#appsecret_proof. , hash_hmac('sha256', access_token, client_secret)

q4) have our own 2 mobile app (each ios , android) , not providing third party use our api develop other apps. means, our client_info table have 2 rows 1 each type of apps. okay, in app code, keep client_key , client_secret hardcoded? if yes, in future when have invalidate , use new secret how achieve replacing info?

q5) since our own apps couple of years, there multiple access_token created against same client_key , client_secret. in order save of them, idea store client_key key , array of access_tokens value in redis. in future, when open our api third party, redis storage design can still scale?

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

later on, user decides perform actions on app, need user login account. user click on "facebook login". app gets facebook access_token , fb user's id facebook , pass info api server (as shown in 2nd diagram). api server takes token , call facebook api validate access_token. once token validated, server uses metadata related user along fb access token generate our own user_access_token, lets utoken. , pass utoken client pass in every subsequent user specific api calls. here questions are:

q1) ok save utoken in database, user_token table. should utoken in plain text or should in decryt-able format? if encrypt it, still need keep encryption key somewhere in system. how make secure? in every call, decryption overhead.

q2) in every user specific api calls, should call facebook every time check facebook access_token still valid? believe should not, not going me. please note, facebook used "facebook login".

q3) information should encrypt generate utoken? thinking have hash or associative array of user's email, user id, role , facebook token , serialize data structure , encrypt it. think enough. understand per requirement, standard or common app, enough? or there best practice?

q4) should client store utoken in cookie/cache? isn't scary?

q5) please note user may have multiple devices, logged in same user credential. means, in user_token table, have store multiple utokens logged-in session, while of them belong same user. sound right?

a design proposal smiliar mine rest api website uses facebook authentication

q1.1: no!. client credentials not intended used way. if client single page app or mobile app, forced store client credentials in insecure environment, user's machine. should using oauth's implicit flow

q1.2: assuming token short lived, no problem caching it. key of oauth, apart ensuring can rely on other application authenticate users, substitute user or application credentials, long lived, short lived token. if gains access token,at least, access system limited in time.

q1.3: check out facebook documentation:

graph api calls can made clients or server on behalf of clients. calls server can better secured adding parameter called appsecret_proof.

it states appsecret_proof used calls server on behalf of user. point here has q1.1. if storing client_secret in user's device, generate appsecret_proof.

q1.4: again, no! should have read of oauth specification , understand different flow types , when use each. bear in mind, if provide api app api public 1 abuse. difference is not documented. same happen web app. once in internet, write scraper , abuse web app. normal, bear in mind on internet not private, undocumented.

q1.5: again, tokens should short lived. if lifespan same of credentials, live until user change them, tokens lose purpose.

q2.1: should save token rest architecture uses client cache constraint.

q2.2: don't think so. facebook telling user obtained token has identity (an email, example) can associate user in system. once know association should't care facebook token make calls facebook api. ass say, using login.

q2.3: seems not bad check again oauth specification seem building implicit flow , using jwt tokens. per want store in token, seems fine.

q2.4: jwt tokens must cached client. nothing scary, because opaque client encrypted. client sends jwt token each request , api server decrypts token private key (that has never been exposed outside server) , can check identity of user.

q2.5: remember short lived tokens. tokens must expire!.