The authorization flow for native apps using the browser acts as illustrated in the following diagram:
Tweet This Authorization Flow for Native Apps Using the Browser "Using the browser to make native app authorization requests results in better security." We'll go into the security and implementation advantages of using the browser for authorization requests in more detail below. Embedded user agents also don't share authentication state, meaning no single sign-on benefits can be conferred. If used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. Embedded user agents are unsafe for third parties.
It also enables use of the user's current authentication state, making single sign-on possible. Using the browser to make native app authorization requests results in better security. Embedded user agents should not be implemented.įor authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views). This document requires that, in accordance with best practices, only external user agents (such as the browser) should be used with the OAuth 2.0 Authorization Framework by native applications this is known as the "AppAuth pattern". The IETF ( Internet Engineering Task Force) recently released the Best Current Practice for OAuth 2.0 for Native Apps Request For Comments. OAuth 2.0 Best Current Practice for Native Apps We'll discuss what this means for developers and users and any security considerations involved. This BCP states that OAuth 2.0 authorization requests from native apps should only be made through external user agents, primarily the user's browser. TL DR: In October, 2017, the Internet Engineering Task Force (IETF) released the Best Current Practices (BCP) when using OAuth 2.0 with native mobile applications.
0 kommentar(er)
