oauth 2.0 - Structure of an oauth2 app -




i'd create oauth2 secured app. provide own oauth2 server called "login.mydomain.com". app accessible through "dashboard.mydomain.com". users visit dashboard.mydomain.com, redirected login.mydomain.com, give credentials , redirected dashboard.mydomain.com.

on dashboard.mydomain.com user able use features provided apis. apis in plural because in specs have minimum 3 apis because services provide these apis 3 different servers different services.

how can provide access_token form login.mydomain.com through dashboard.mydomain.com 1 of api check if user allowed executed requested feature? api able proof authorization access_token given or client_id , according client_secret needed in api part proof against login.mydomain.com, oauth2 service?

what normal way hold user information? - first need user entity in login able proof given password user. - second need user entity in dashboard able connect data within dashboard app user. - third need user entity in api able hold permissions in acls configure user may use what.

is structure usable in form or acls better held centralized in dashboard, no api calls generated when user not allowed execute method. structure, however, stop me providing api outside world. dashboard may talk apis because i'm able trust dashboard out of view api.

can give me advice on how structure such scenario or point me documentation can further information that?

cheers andi





wiki

Comments

Popular posts from this blog

Asterisk AGI Python Script to Dialplan does not work -

kotlin - Out-projected type in generic interface prohibits the use of metod with generic parameter -

python - Read npy file directly from S3 StreamingBody -