Welcome @alex.bsky.team !
Here’s the first in what I’m hoping will become a regular DevRel blog series:
4 Likes
Welcome Alex, excited to see the documentation/tooling improve in the future.
Thanks @thisismissem.social and apologies for not getting back sooner. I think with the recent change to the Bluesky PDS fleet today, which seems to have broken the verification I had in place using the public JWK, I’m going to have to look for a different approach.
It seems the latest update has included some of those changes, so the approach I was using is no longer viable. I’m curious: is there an XRPC endpoint I can call using only the atproto scope so I can verify that the access token a public client has obtained indeed came from the user’s PDS?
1 Like
Hey @davenash.com! Curious what you’re trying to do here, are you able to use com.atproto.server.getSession or does that not fit your use case?
OAuth access tokens are bound to DPoP keys which should not leave their device/server, ie not meant for sharing access tokens between systems.
1 Like
Hi @alex.bsky.team, yeah, the more I think about it, the more I realise I am trying to do something DPoP is meant to guard against. I was hoping to implement an approach that would allow the user to complete a login using the browser as a public client, then pass the access token to a backend for it to verify the user (using the JWKs) before serving the content. I will handle this process entirely in the backend using a confidential client instead.
2 Likes
Wanted to also introduce myself – I’m Jim, I’ve also recently joined Team Bluesky on the DevRel side. Before Bluesky, I ran developer success at Slack, and various tech/media/design things before that. I’m incredibly excited about what we’re building here and especially about what the global community is creating.
I’ll be working with Alex on improving all things related to the developer experience. Please say hi here or jimray.bsky.team. Onward!
10 Likes