Difference between revisions of "Proof Key for Code Exchange"
From MgmtWiki
(→Context) |
(→Solutions) |
||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==Full Title== | ||
| − | PKCE (Proof Key for Code Exchange | + | PKCE (Proof Key for Code Exchange) to protect communications with [[Smart Phone]] [[Native App]]s |
| + | |||
==Context== | ==Context== | ||
| + | RFC 7636 is the Proof Key for Code Exchange limited to OAuth Public Clients | ||
| − | OAuth 2.0 is the preferred mechanism for authorizing native mobile applications to their corresponding API endpoints. In order to be authorized, the native application attaches an OAuth access token to its API calls. Upon receiving a call, the API extracts the token, validates it (checks issuer, lifetime, associated authorizations, etc) and then determines whether the request should be allowed or denied. | + | [[OAuth 2.0]] is the preferred mechanism for authorizing native mobile applications to their corresponding API endpoints. In order to be authorized, the native application attaches an OAuth access token to its API calls. Upon receiving a call, the API extracts the token, validates it (checks issuer, lifetime, associated authorizations, etc) and then determines whether the request should be allowed or denied. |
Of course, before the native application can use an access token on an API call, it must necessarily have first been issued that token. OAuth defines how the native application, with a user’s active involvement, interacts with an Authorization Server (AS) in order to obtain a set of tokens that represent that user and their permissions. The best practice for native applications leverages a version of OAuth called the ‘authorization code grant type’ – which in this context consists of the following steps | Of course, before the native application can use an access token on an API call, it must necessarily have first been issued that token. OAuth defines how the native application, with a user’s active involvement, interacts with an Authorization Server (AS) in order to obtain a set of tokens that represent that user and their permissions. The best practice for native applications leverages a version of OAuth called the ‘authorization code grant type’ – which in this context consists of the following steps | ||
| Line 14: | Line 16: | ||
##may obtain the user’s consent for the operations for which the native application is requesting permission | ##may obtain the user’s consent for the operations for which the native application is requesting permission | ||
#If step 4 is successful, the AS builds a URL in the scheme belonging to the native application and adds an authorization code to the end of the URL, e.g. ‘com.example.mobileapp://oauth?code=123456. The AS directs the user’s browser to redirect to this URL | #If step 4 is successful, the AS builds a URL in the scheme belonging to the native application and adds an authorization code to the end of the URL, e.g. ‘com.example.mobileapp://oauth?code=123456. The AS directs the user’s browser to redirect to this URL | ||
| − | #The browser queries the mobile OS to determine how to handle this URL. The OS determines the appropriate handler, and passes the URL to the | + | #The browser queries the mobile OS to determine how to handle this URL. The OS determines the appropriate handler, and passes the URL to the application that is registered to that URL |
#The native application parses the URL and extracts the authorization code from the end | #The native application parses the URL and extracts the authorization code from the end | ||
#The native application sends the authorization code back to the AS | #The native application sends the authorization code back to the AS | ||
| Line 20: | Line 22: | ||
#The native application then stores that access token away in secure storage so it can be subsequently used on API calls. | #The native application then stores that access token away in secure storage so it can be subsequently used on API calls. | ||
| − | https://tools.ietf.org/html/draft-ietf-oauth-spop | + | ==Problems== |
| + | # There is relatively little security in the registration for a URL on the [[Smart Phone]]. Another app can come in and try to grab that registration. | ||
| + | # The smartphone app stores offer protection for devices loaded by users so that the user can know the source of any native app. The first use for that native app could perform registration with a Credential Service Provider which included generation of private key protected by hardware key stores on any phone where the current os was issued since 2019. | ||
| + | |||
| + | ==Solutions== | ||
| + | # [https://tools.ietf.org/html/draft-ietf-oauth-spop draft standard] for SPOP | ||
| + | # RFC 7636 ''Proof Key for Code Exchange by OAuth Public Clients'' . 2015-09 | ||
| + | # [https://www.oauth.com/oauth2-servers/pkce/ Protecting Mobile Apps with PKCE] from okta | ||
| + | # [https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce/?utm_campaign=text_website_all_multiple_dev_dev_oauth-pkce_null Proof Key for Code Exchange (PKCE)] - Micah Silverman Okta - ''Implement the OAuth 2.0 Authorization | ||
| + | # [https://oauth.net/2/pkce/ RFC 7636: Proof Key for Code Exchange] on the oauth.net web site. | ||
| + | Code with PKCE Flow'' | ||
| + | ===Blue Button CMS=== | ||
| + | [https://bluebutton.cms.gov/developers/ The US HHS CMS implementation] includes the following guidance | ||
| + | *Native Mobile App Support follows the RFC 8252 - OAuth 2.0 for Native Apps authentication flow utilizing the PKCE extension and enables a custom URI scheme redirect. | ||
| + | *The implementation of the RFC 8252 specification enables developers to build mobile applications without requiring a proxy server to route redirect calls to their mobile app. | ||
| + | *The PKCE extension provides a technique for public clients to mitigate the threat of a “man-in-the-middle” attack. This involves creating a secret that is used when exchanging the authorization code to obtain an access token. | ||
| + | *PKCE uses a code challenge that is derived from a code-verifier. The standard supports two styles of code challenge: | ||
| + | plain | ||
| + | S256 | ||
| + | However, Blue Button 2.0 only supports the “S256” style code challenge. Where the: | ||
| + | codechallenge = BASE64URL-ENCODE(SHA256(ASCII(codeverifier))) | ||
| + | The following additional parameters and values are sent as part of the OAuth2.0 Authorization Request: | ||
| + | code_challenge | ||
| + | codechallengemethod = “S256”. | ||
| + | |||
| + | ==References== | ||
| + | |||
| + | * See the wiki page [[Native App Security]] for the context of this method. | ||
| + | |||
| + | [[Category:Glossary]] | ||
| + | [[Category:Authorization]] | ||
Latest revision as of 15:10, 22 June 2021
Full Title
PKCE (Proof Key for Code Exchange) to protect communications with Smart Phone Native Apps
Context
RFC 7636 is the Proof Key for Code Exchange limited to OAuth Public Clients
OAuth 2.0 is the preferred mechanism for authorizing native mobile applications to their corresponding API endpoints. In order to be authorized, the native application attaches an OAuth access token to its API calls. Upon receiving a call, the API extracts the token, validates it (checks issuer, lifetime, associated authorizations, etc) and then determines whether the request should be allowed or denied.
Of course, before the native application can use an access token on an API call, it must necessarily have first been issued that token. OAuth defines how the native application, with a user’s active involvement, interacts with an Authorization Server (AS) in order to obtain a set of tokens that represent that user and their permissions. The best practice for native applications leverages a version of OAuth called the ‘authorization code grant type’ – which in this context consists of the following steps
- Upon installation, the native application registers itself with the mobile OS as the handler for URLs in a particular scheme, e.g. those starting with ‘com.example.mobileapp://’ as opposed to ‘http://’.
- After installation, the native application invites the user to authenticate.
- The native application launches the device system browser and loads a page at the appropriate AS.
- In that browser window, the AS:
- authenticates the user. Because authentication happens in a browser, the AS has flexibility in the how & where the actual user authentication occurs, i.e., it could be through federated SSO or could leverage 2 Factor Authentication etc. There are advantages to using the system browser and not an embedded browser – notably that a) any credentials presented in the browser window are not visible by the application b) any session established in the browser for one native application can be used for a second, enabling a SSO experience
- may obtain the user’s consent for the operations for which the native application is requesting permission
- If step 4 is successful, the AS builds a URL in the scheme belonging to the native application and adds an authorization code to the end of the URL, e.g. ‘com.example.mobileapp://oauth?code=123456. The AS directs the user’s browser to redirect to this URL
- The browser queries the mobile OS to determine how to handle this URL. The OS determines the appropriate handler, and passes the URL to the application that is registered to that URL
- The native application parses the URL and extracts the authorization code from the end
- The native application sends the authorization code back to the AS
- The AS validates the authorization code and returns to the native application an access token (plus potentially other tokens)
- The native application then stores that access token away in secure storage so it can be subsequently used on API calls.
Problems
- There is relatively little security in the registration for a URL on the Smart Phone. Another app can come in and try to grab that registration.
- The smartphone app stores offer protection for devices loaded by users so that the user can know the source of any native app. The first use for that native app could perform registration with a Credential Service Provider which included generation of private key protected by hardware key stores on any phone where the current os was issued since 2019.
Solutions
- draft standard for SPOP
- RFC 7636 Proof Key for Code Exchange by OAuth Public Clients . 2015-09
- Protecting Mobile Apps with PKCE from okta
- Proof Key for Code Exchange (PKCE) - Micah Silverman Okta - Implement the OAuth 2.0 Authorization
- RFC 7636: Proof Key for Code Exchange on the oauth.net web site.
Code with PKCE Flow
Blue Button CMS
The US HHS CMS implementation includes the following guidance
- Native Mobile App Support follows the RFC 8252 - OAuth 2.0 for Native Apps authentication flow utilizing the PKCE extension and enables a custom URI scheme redirect.
- The implementation of the RFC 8252 specification enables developers to build mobile applications without requiring a proxy server to route redirect calls to their mobile app.
- The PKCE extension provides a technique for public clients to mitigate the threat of a “man-in-the-middle” attack. This involves creating a secret that is used when exchanging the authorization code to obtain an access token.
- PKCE uses a code challenge that is derived from a code-verifier. The standard supports two styles of code challenge:
plain S256
However, Blue Button 2.0 only supports the “S256” style code challenge. Where the:
codechallenge = BASE64URL-ENCODE(SHA256(ASCII(codeverifier)))
The following additional parameters and values are sent as part of the OAuth2.0 Authorization Request:
code_challenge codechallengemethod = “S256”.
References
- See the wiki page Native App Security for the context of this method.
