* Ensure that the credentials used during a refresh correspond to those used to create the OAuth tokens. * tidy * Bind the OAuth session to the kid that was used to authenticate the client (private_key_jwt) * Store the whole authentication method in the client session store rather than the kid only * tidy * Improve error reporting in case an invalid `token_endpoint_auth_method` is used in the client metadata document. * tidy * tidy * Improve JAR checks * tidy * changeset * tidy * Remove schema's `.optional()` modifier when a `.default()` is defined * tidy * verify client auth during code exchange * tidy * Minor naming improvement * tidy * Update .changeset/quiet-pans-fix.md Co-authored-by: devin ivy <devinivy@gmail.com> * Update packages/oauth/oauth-client/src/oauth-client-auth.ts * Use `private_key_jwt` instead of incorrect `client_secret_jwt` as authentication method for confidential clients * style * code split * dead code removal * Represent missing client auth with a `null` instead of "none" when storing request data. * Allow storing `null` in authorization_request's `clientAuth` json column * document * tidy * Remove non-standard behavior that allowed client to authenticate through JAR * Improved error messages * Parse JSON encoded Authorization Request Parameters * Use `application/x-www-form-urlencoded` content instead of JSON for OAuth requests Fixes: #3723 * tidy * tidy * tidy * tidy * code style * remove un-necessary checks * tidy * Pre-process number too * improved type checking * add missing exports * fix merge conflict * tidy * Remove invalid default for `code_challenge_method` authorization request parameter * tidy * Delete inaccurate changeset * PR comment * tidy * Update OAuth client credentials factory to return headers and payload separately. * tidy * Renamed `clientAuthCheck` to `validateClientAuth` * Validate presence of DPoP proofs sooner when processing token requests. Fixes: #3859 * Protect against concurrent use of request code * tidy * tidy * Update packages/oauth/oauth-provider/src/client/client.ts Co-authored-by: devin ivy <devinivy@gmail.com> * Review comments * Add missing `exp` claim in client attestation JWT * fixup! Review comments * Review comments * Refactor: explicit optionality of unsigned JAR issuer & audience * Use client attestation's `exp` claim to determine the life time of JWT's `jti` nonce. * Fix PDS: consumeRequestCode should delete request data * tidy * tidy * Unused code removal * Restore "Native clients must authenticate using "none" method" check * tidy * tidy * cleanup * comment * Allow missing DPoP header during PAR request if `dpop_jkt` is provided * tidy --------- Co-authored-by: devin ivy <devinivy@gmail.com>
AT Protocol Reference Implementation (TypeScript)
Welcome friends!
This repository contains Bluesky's reference implementation of AT Protocol, and of the app.bsky
microblogging application service backend.
What is in here?
TypeScript Packages:
Package | Docs | NPM |
---|---|---|
@atproto/api : client library |
README | |
@atproto/common-web : shared code and helpers which can run in web browsers |
README | |
@atproto/common : shared code and helpers which doesn't work in web browsers |
README | |
@atproto/crypto : cryptographic signing and key serialization |
README | |
@atproto/identity : DID and handle resolution |
README | |
@atproto/lexicon : schema definition language |
README | |
@atproto/repo : data storage structure, including MST |
README | |
@atproto/syntax : string parsers for identifiers |
README | |
@atproto/xrpc : client-side HTTP API helpers |
README | |
@atproto/xrpc-server : server-side HTTP API helpers |
README |
TypeScript Services:
pds
: "Personal Data Server", hosting repo content for atproto accounts. Most implementation code inpackages/pds
, with runtime wrapper inservices/pds
. See bluesky-social/pds for directions on self-hosting.bsky
: AppView implementation of theapp.bsky.*
API endpoints. Running on main network atapi.bsky.app
. Most implementation code inpackages/bsky
, with runtime wrapper inservices/bsky
.
Lexicons: for both the com.atproto.*
and app.bsky.*
are canonically versioned in this repo, for now, under ./lexicons/
. These are JSON files in the Lexicon schema definition language, similar to JSON Schema or OpenAPI.
Interoperability Test Data: the language-neutral test files in ./interop-test-files/
may be useful for other protocol implementations to ensure that they follow the specification correctly
The source code for the Bluesky Social client app (for web and mobile) can be found at bluesky-social/social-app.
Go programming language source code is in bluesky-social/indigo, including the BGS implementation.
Developer Quickstart
We recommend nvm
for managing Node.js installs. This project requires Node.js version 18. pnpm
is used to manage the workspace of multiple packages. You can install it with npm install --global pnpm
.
There is a Makefile which can help with basic development tasks:
# use existing nvm to install node 18 and pnpm
make nvm-setup
# pull dependencies and build all local packages
make deps
make build
# run the tests, using Docker services as needed
make test
# run a local PDS and AppView with fake test accounts and data
# (this requires a global installation of `jq` and `docker`)
make run-dev-env
# show all other commands
make help
About AT Protocol
The Authenticated Transfer Protocol ("ATP" or "atproto") is a decentralized social media protocol, developed by Bluesky Social PBC. Learn more at:
- Overview and Guides 👈 Best starting point
- Github Discussions 👈 Great place to ask questions
- Protocol Specifications
- Blogpost on self-authenticating data structures
The Bluesky Social application encompasses a set of schemas and APIs built in the overall AT Protocol framework. The namespace for these "Lexicons" is app.bsky.*
.
Contributions
While we do accept contributions, we prioritize high quality issues and pull requests. Adhering to the below guidelines will ensure a more timely review.
Rules:
- We may not respond to your issue or PR.
- We may close an issue or PR without much feedback.
- We may lock discussions or contributions if our attention is getting DDOSed.
- We do not provide support for build issues.
Guidelines:
- Check for existing issues before filing a new one, please.
- Open an issue and give some time for discussion before submitting a PR.
- If submitting a PR that includes a lexicon change, please get sign off on the lexicon change before doing the implementation.
- Issues are for bugs & feature requests related to the TypeScript implementation of atproto and related services.
- For high-level discussions, please use the Discussion Forum.
- For client issues, please use the relevant social-app repo.
- Stay away from PRs that:
- Refactor large parts of the codebase
- Add entirely new features without prior discussion
- Change the tooling or frameworks used without prior discussion
- Introduce new unnecessary dependencies
Remember, we serve a wide community of users. Our day-to-day involves us constantly asking "which top priority is our top priority." If you submit well-written PRs that solve problems concisely, that's an awesome contribution. Otherwise, as much as we'd love to accept your ideas and contributions, we really don't have the bandwidth.
Are you a developer interested in building on atproto?
Bluesky is an open social network built on the AT Protocol, a flexible technology that will never lock developers out of the ecosystems that they help build. With atproto, third-party can be as seamless as first-party through custom feeds, federated services, clients, and more.
Security disclosures
If you discover any security issues, please send an email to security@bsky.app. The email is automatically CCed to the entire team, and we'll respond promptly. See SECURITY.md for more info.
License
This project is dual-licensed under MIT and Apache 2.0 terms:
- MIT license (LICENSE-MIT.txt or http://opensource.org/licenses/MIT)
- Apache License, Version 2.0, (LICENSE-APACHE.txt or http://www.apache.org/licenses/LICENSE-2.0)
Downstream projects and end users may chose either license individually, or both together, at their discretion. The motivation for this dual-licensing is the additional software patent assurance provided by Apache 2.0.