Implementing the ATOAuthKit client

[systemblueio]

MasterJ93/ATProtoKit#43 closes when this package ships its client, tests, and README. I'd be up for taking that on if you're open to it, following @atproto/oauth-client@0.7.x the way OAuthTypes follows @atproto/oauth-types.

Proposed sequence, one PR per phase:

1. Complete OAuthTypes: port the missing atproto modules (atproto-oauth-scope, atproto-loopback-client-id, atproto-loopback-client-redirect-uris, atproto-oauth-token-response, oauth-introspection-response), add Sendable conformance for strict-concurrency consumers, restore the client_id requirement on AuthorizationRequestQuery (the TS schema is an intersection), and harden the canonical-form check against percent-encoded dot segments, with conversion docs and tests.
2. Client foundation: the store and cache layer (SimpleStore, a single-flight CachedGetter actor), the runtime seam (key generation, SHA-256, secure random, named locks), Key/Keyset over Jot and JWTKit, DPoP proof minting, PKCE, RFC 7638 thumbprints.
3. Resolvers: DID, handle, and identity resolution with bidirectional verification, plus the authorization-server and protected-resource metadata resolvers.
4. Client core: OAuthServerAgent, SessionGetter (refresh with single-use refresh-token race handling), OAuthSession (DPoP-bound fetch with nonce retry), OAuthClient, and client-metadata validation.
5. Docs: README, DocC, and a SessionConfiguration bridge example for ATProtoKit.

The port would target current spec behavior where it has drifted since the TS snapshot: htu stripped of query and fragment, no iss claim in resource-server DPoP proofs, form-encoded PAR with dpop_jkt, an exp claim in client assertions, and the June 2025 session-lifetime changes. Granular scopes stay out until they stabilize; transition scopes only.

Does this direction work, or would you shape the phases differently? Related: #1 fixes the existing OAuthTypes validators ahead of any of this.

[MasterJ93]

Sorry for taking long in responding; I've only saw this today. I'll have to properly read and digest what you wrote, so please just wait a little bit longer.

[systemblueio]

Sorry for taking long in responding; I've only saw this today. I'll have to properly read and digest what you wrote, so please just wait a little bit longer.

all good. happy to help.

[MasterJ93]

Sorry for taking long. I meant to respond earlier but something came up.

I think for the first version, this is okay. We'll need to modify it a lot more over time, but for now, I'll accept it. I will review the code line by line to ensure that everything fits within the design that I've been hoping to see. There is another reason why I'm doing it line by line: because this is such a security-conscious package, I want to ensure that there aren't any issues with the code in terms of accidental vulnerabilities. So it may take a while for me to look through all of the code. Finally, please make sure that the code works not only on Apple platforms, but on Linux, Android, and Windows as well. We won't focus on Wasm just yet, as ATProtoKit itself doesn't compile in Wasm.

I will deal with the README, as I have an explicit way of writing things out in there. Same with the .docc-related files (but please do add the inline documentation on all public, internal, and private declarations; the latter two because developers should still be able to inspect the code and understand what the declaration does and why it exists.

There's also the fact that I'm a stickler for clean code, and I'm always improving on it, so please understand that I'm not trying to be a jerk when I say that something looks off or "this line should be a certain lines of characters long." While I do have some inconsistencies myself, I'm always looking through my own code and correcting them as needed. The goal is to have clean, understandable code so that developers can have the clearest understanding of what's happening and why it exists. But generally speaking:

• The Swift API Design Guidelines is the absolute authority with respect to how things should be written.
• The ATProtoKit API Design Guidelines, while incomplete, should still be useful enough. I do intend on completing it, but there's quite a few things that I'm considering, or that I can see in my head but unable to produce into words.

If you have any questions, please let me know. And I apologize if I sound difficult; I just want everything to work the way it should work so developers aren't scratching their heads.

[systemblueio]

No need to apologize. Starting on phase 1 now.