OAuth: Getting Access Token

Development API development and support
1

I am writing an example OpenID based client that registers itself with a diaspora pod, gets user authorization to grant access to user’s posts, gets an access token from the pod, then downloads and displays posts.

I’m trying to replicate the process outlined here:

Server is diaspora version “0.7.99.0-p2da33408”

Requesting access tokens fail with an “invalid_client” error. I’m uncertain why. If someone could provide guidance in this matter I’d be very thankful.

The relevant part of the OAuth process goes like this:

Posted To Diaspora Server
http_post_json(): POST http://0.0.0.0:3000/api/openid_connect/clients
{
"application_type":"native",
"client_name":"diaspora_client_example",
"redirect_uris":["http://127.0.0.1:65080"]
}

Diaspora Server Response
{
…
"client_id":"09d9ac91bedef649f3d24dd1af169741",
"client_secret":"7d6f5c4760a9aef814a4e080be50871b4fa83dd4be104a4ef128a404b75af205"
…
}

User Confirmation Opened in Web Browser:

http://0.0.0.0:3000/api/openid_connect/authorizations/new?response_type=code&client_id=09d9ac91bedef649f3d24dd1af169741&redirect_uri=http%3A%2F%2F127.0.0.1%3A65080&scope=openid%20public%3Aread&state=bbbc1d2a&code_challenge=8QzQ-BDrKdh_xf3qHBjIl9wRrcfhhkXRA9qa8jnSEm4&code_challenge_method=S256

The code challenge:
8QzQ-BDrKdh_xf3qHBjIl9wRrcfhhkXRA9qa8jnSEm4

is hard coded (not in git repo) SHA256 hash + Base64 encoded random string:
b4d47cf95aba2337dcf50f7be72d589938dfd03b54edc1f59144eedd

SHA256 + Base64 encoding was generated by this page:
https://example-app.com/pkce

Redirect URL With Client Confirmation Code
GET /?code=9d47e736f02bbb6e90032fbca96f1cf1687c4a3d3b6fda3947f09791554b1564&state=bbbc1d2a HTTP/1.1

Access Token Request Posted To Diaspora Server
http_post_enc(): POST http://0.0.0.0:3000/api/openid_connect/access_tokens

urlencoded data:
grant_type=authorization_code&
code=9d47e736f02bbb6e90032fbca96f1cf1687c4a3d3b6fda3947f09791554b1564&
redirect_uri=http%3A%2F%2F127.0.0.1%3A65080&
client_id=09d9ac91bedef649f3d24dd1af169741&
code_verifier=b4d47cf95aba2337dcf50f7be72d589938dfd03b54edc1f59144eedd

Diaspora Server Response
{
"error":"invalid_client",
"error_description":"The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type."
}

2

I didn’t verify but I think you’re missing the client_secret in the request to the access token.

In the registration endpoint you should have a token_endpoint_auth_method method field. If your request didn’t specify one, the default should be client_secret_post, so the client secret is required when exchanging the authorization code for an access token. (When exchanging the refresh token for a new access token too, I think).

OpenID Connect probably deviates here a bit from standard OAuth2.

Spec references:

1 Like
3

Yes! It works! I can now access things through the API. Thank you so much.

Let me know if there’s anything in the API I can test for you.

Next question - I see that the id_token field contains a JSON Web Signature (JWS) which according to the RFC relies on cryptography for validation.

I’m not a cryptographer. I see here that there’s a JavaScript library called openid-client but it depends on Node.js. I don’t currently have experience with Node.js but from reading the introductory material it seems far too extensive for a small application like this.

Do you or anyone else here have a preferred javascript/C/C++ library which fits within the scope of a standalone client app that can verify the JWS signature?

Again, thank you for the help.

4

No, I didn’t dive much into that part of the authorization process either yet :confused:

Just generally watch out for inconsistencies or anything that makes client implementation life hard, so mostly “Oh I wish this was returned here instead of me having to do another API call” and “I can’t get the right information to do X” kind of stuff. I think there also still might be some rough edges around error handling and maybe scopes/authorization. Just mention anything you notice at this point really :slight_smile: