User:Premeditated/oauth

In 2015, the Internet Engineering Task Force (IETF) published an RFC that described a new technique for native app authentication called Proof Key For Code Exchange. PKCE — pronounced “pixy” — is similar to the classic OAuth 2.0 authorization code flow with a few changes. Before beginning the authentication process, an app using PKCE will generate a code challenge and a code verifier. The code challenge — a hash of the code verifier — is passed to the authorization server when a user begins the OAuth flow. Later, when requesting an access token, the app sends the code verifier to the authorization provider. This technique allows third-party apps to securely fetch a refreshable access token without a client secret, and it helps to mitigate some security problems that can affect mobile apps using other OAuth flows.
 * What is PKCE?

The authorization code flow with PKCE is the best option for mobile and desktop applications where it is unsafe to store your client secret. It provides your app with an access token that can be refreshed. For further information about this flow, see IETF RFC-7636.
 * Authorization Code Flow with Proof Key for Code Exchange (PKCE)



1. Create the code verifier and challenge
Before each authentication request your app should generate a code verifier and a code challenge. The code verifier is a cryptographically random string between 43 and 128 characters in length. It can contain letters, digits, underscores, periods, hyphens, or tildes.

In order to generate the code challenge, your app should hash the code verifier using the SHA256 algorithm. Then, base64url encode the hash that you generated.

2. Construct the authorization URI
The authorization URI is a Spotify endpoint that displays a permissions dialog to the user. This URI begins with https://www.wikidata.org/w/rest.php/oauth2/authorize and your app should add the URL query parameters that are described below.