Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENHANCEMENT] RFC-9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP) #3

Open
codemasher opened this issue May 13, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@codemasher
Copy link
Member

codemasher commented May 13, 2024

Describe the feature

The feature is documented in RFC-9449.

Right now I don't see the need to implement abstract support for this, as there are currently no major services out in the wild that support it (as it is a relatively new proposal).
Further, the underlying protocol has a lot of dependencies (RFCs 7515, 7516, 7517, 7518, 7519, 7520, 7521, 7523) that translate into one or more additional libraries, such as firebase/php-jwt or web-token/jwt-framework for example, which is not justifiable at this point.
Bluesky's upcoming OAuth2 support might be the first implementation that makes use of it, and once it is rolled out, I'll figure out implementation details and whether to depend on external libraries or just roll a minimum JWT implementation for this specific provider.

Code sample (if applicable)

DPoP introduces the concept of a DPoP proof, which is a JWT created by the client and sent with an HTTP request using the DPoP header field. Each HTTP request requires a unique DPoP proof.

The DPoP proof is sent with the access token request, hence it should be created once the authorization code is received, so in OAuth2Provider::getAccessToken(). Ideal is probably OAuth2Provider::sendAccessTokenRequest() which is called in the aforementioned method and which has direct access to the PSR-7 RequestInterface instance:

	protected function sendAccessTokenRequest(string $url, array $body):ResponseInterface{

		$request = $this->requestFactory
			->createRequest('POST', $url)
			->withHeader('Accept', 'application/json')
			->withHeader('Accept-Encoding', 'identity')
			->withHeader('Content-Type', 'application/x-www-form-urlencoded')
			->withBody($this->streamFactory->createStream(QueryUtil::build($body, PHP_QUERY_RFC1738)))
		;

		foreach($this::HEADERS_AUTH as $header => $value){
			$request = $request->withHeader($header, $value);
		}

		if($this::USES_BASIC_AUTH_IN_ACCESS_TOKEN_REQUEST){
			$request = $this->addBasicAuthHeader($request);
		}

		// as with all additional features, an interface will be added
		if($this instanceof DPoP){
			$dpopProof = $this->createDpopProof(/* ... */);

			$request = $request->withHeader('DPoP', $dpopProof);
		}

		return $this->http->sendRequest($request);
	}

During creation of the proof, the generated private key should be saved for the current user, which requires additional methods in the storage interface as the key is required for subsequent proofs:

  • OAuthStorageInterface::storeDpopPrivateKey(string $key, string $provider):static
  • [get, has, clear, clearAll...]

No changes are required to the token response parser or the AccessToken class as the only difference here is that the access token is a JWT that contains data instead of a random string.

The request authorization boils down to:

	public function getRequestAuthorization(RequestInterface $request, AccessToken|null $token = null):RequestInterface{
		$token ??= $this->storage->getAccessToken($this->name);

		if($token->isExpired()){

			if(!$this instanceof TokenRefresh || $this->options->tokenAutoRefresh !== true){
				throw new InvalidAccessTokenException;
			}

			$token = $this->refreshAccessToken($token);
		}

		return $request
			// the "Bearer" changes to "DPoP" as per spec (or whatever the service doc says)
			->withHeader('Authorization', 'DPoP '.$token->accessToken)
			// additionally, a DPoP proof is attached
			->withHeader('DPoP', $this->createDpopProof(/* ... */))
		;
	}

Are you (the requester) willing to submit a pull request for that feature?

[YES] (I guess I'll have to!?)

@codemasher codemasher added the enhancement New feature or request label May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant