Proof Key for Code Exchange - Revision history

Tom: /* Solutions */

2021-06-22T22:10:23Z

‎Solutions

2020-08-20T17:05:03Z

‎Problems

2020-08-20T17:04:33Z

‎Problems

2020-08-20T17:00:28Z

‎Solutions

2020-08-20T16:59:03Z

‎Context

2020-08-20T16:54:53Z

‎Context

2020-08-20T16:52:15Z

‎References

2020-02-21T18:23:01Z

‎Full Title

2020-02-21T17:31:28Z

‎Full Title

2020-02-21T17:30:38Z

‎Context

@@ Line 30: / Line 30: @@
 # 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 Code with PKCE Flow''
+# [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
 ===Blue Button CMS===
 [https://bluebutton.cms.gov/developers/ The US HHS CMS implementation] includes the following guidance

@@ Line 24: / Line 24: @@
 ==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 an any phone where the current os was issued since 2019.
+# 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==

@@ Line 24: / Line 24: @@
 ==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.
 ==Solutions==

@@ Line 26: / Line 26: @@
 ==Solutions==
-# [https://tools.ietf.org/html/draft-ietf-oauth-spop draft standard]
+# [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

@@ Line 16: / Line 16: @@
 ##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 appropriate application
+#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

@@ Line 5: / Line 5: @@
 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

@@ Line 45: / Line 45: @@
 ==References==
 [[Category:Glossary]]
 [[Category:Authorization]]

@@ Line 1: / Line 1: @@
 ==Full Title==
-PKCE (Proof Key for Code Exchange)
+PKCE (Proof Key for Code Exchange) to protect communications with [[Smart Phone]] [[Native App]]s
 ==Context==