api - Correct Usage of OAuth 2.0 Grant Types -


in following sum our argumentation using oauth 2.0 grant types in 2 scenarios , kindly ask community either agree our argumentation or identify weaknesses.

the overall goal protect enterprise api using oauth 2.0. use case of oauth 2.0 distinguish 2 scenarios:

  • scenario a: api used application developed third party, e.g. application available app-store uses our api.

  • scenario b: in-house developed application uses api, e.g. single-page web-application uses restful api.

we use gateway (which embeds reverse proxy , oauth 2.0 client) in order hide internal api security mechanism , not expose access tokens public. gateway handles both dynamic routing , mapping between sessions on customer side , access tokens on internal side. relying on cookie-based session management, allows benefit established session protection mechanisms , enables single-sign-on capabilities different client applications. use jwt bearer tokens authorize calls between gateway , apis.

in both our scenarios, oauth 2.0 client under our control , can considered confidential.

according our understanding, 2 scenarios have different protection requirements:

  • scenario a: application code not under our control , may contain malicious components. want prevent application getting hold of user credentials or access tokens. using authorization code grant type, resource owner authenticates against our platform (redirected our oauth 2.0 authorization server) , grants access resources.

securing apis public application calls oauth 2.0

  • scenario b: time application code under our control, i.e. know code not contain malicious functionality. can therefore trust application process user credentials reliably. consequence propose use resource owner password credentials grant type. in case resource owner credentials exchanged access token using single request without requiring resource owner approve access resources.

securing apis homemade application calls oauth 2.0

in both scenarios, jwt bearer token not leave our platform , used between gateway , corresponding apis, whereas communication user agent (typically browser) uses classical cookie-based session management. consequence of setup enable session based single-sign-on capabilities on user side, whereas allow stateless api-design required in modern architecture styles such rest.

in regular oauth 2.0 scenario, both web app , mobile app oauth 2.0 clients in own right. of course possible oauth 2.0 between gateway , backends well, makes sense use standard protocol towards web app , mobile app, since latter developed 3-rd party.

weirdly enough reasoning correct , valid situation web app , mobile app oauth 2.0 clients. situation private gateway oauth 2.0 client in pure internal scenario, security considerations , standardization less relevant.

so question is: type of authentication/authorization use web app , mobile app. latter interesting know how communication between mobile app secured , authenticated. believe leg begs oauth 2.0. way in web app presents username password private gateway, , way in session or token maintained after that, begs oauth 2.0.

(but perhaps picture mis-representation , text matters here)


Comments

Popular posts from this blog

c# - Where does the .ToList() go in LINQ query result -

Listeners to visualise results of load test in JMeter -