MasterJ93
[Feature Request]: OAuth Support for ATProtoKit
Summary
OAuth support will need to be implemented for authenticating through the AT Protocol services.
Pain points
App Passwords will be eventually deprecated. ATProtoKit needs to get ahead of this by implementing OAuth, which will be the new way for users to log into Bluesky and other services that are built on the AT Protocol.
Considered Alternatives
No response
Is this a breaking change?
No
Library Examples
The Rust API library has implemented OAuth from what I can gather. We can possibly convert the Rust code into Swift code.
Additional Context
This is a fairly difficult part of the AT Protocol to understand. Even if I look at the Rust API library linked above and convert it into Swift code, it's still going to be challenging to understand.
This will most likely require multiple pull requests and iterations before it works as well as the official TypeScript API library.
That said, for future reference, these are some links that may help:
- Bluesky Doc's webpage for OAuth.
- AT Protocol Doc's webpage for OAuth.
- The original design specification proposal.
- The last one is not authoritative, but it may help.
You should consider using a third party library like https://github.com/ChimeHQ/OAuthenticator to get the initial implementation in place, then decide if you need to build this out yourself.
I'll look into that library and see if it works well for my needs. But I fear that I will have to write it by scratch after all (or at least grab a few projects and put them together).
With social cards now available, this is my next-most-wanted feature. :-)
I understand this and I'm working on trying to figure out a solution. I'll soon release a branch of my progress with this and I hope that others will be able to help contribute code and other ideas into this, since this is a top priority for me as well.
I just want to do this right: OAuth is a fairly complicated thing to understand.
Of course! Completely fine to take your time, thank you so much for all the work you're doing on this.
Hey @MasterJ93! Just wanted to drop back into your DMs with news of this OAuth implementation made by Matt Massicotte.
https://github.com/ChimeHQ/OAuthenticator
I wonder if this might help with your implementation? I'm still desperate to have it, in case you wondered... 😬 ❤
I'm well aware of that and I plan on having a tutorial of implementing that once I get the session configuration rework made. Please note that that repository requires Swift 5.10 or later.
Thanks Christopher. Swift 5.10 won't be an impediment to my implementation; I'm looking forward to seeing what you've got!
This part of the project is more or less going to be a summer project, as there's a ton of moving parts that I need to implement before I can properly work on this.
Hey @MasterJ93 just sending my warmest wishes for this project. As I've said before, Bluesky auth remains the number one problem for users of my Bluesky app. There've been a rash of complaints lately so I just wanted to check in and see if work is moving forward on this? 🙏
This is an extremely complicated part of the AT Protocol, so while I have laid the groundwork on it, it's been extremely slow. This is on top of all of the other AT Protocol-related projects I've been working on. That's not an excuse but rather an explanation, and so I apologize for that; I'll try my best to get OAuth support ready as soon as possible, but it will take some time to not only have it ready, but easy enough to just plug into ATProtoKit.
However, I believe ATProtoKit should have enough hooks to use something like OAuthenticator to add in OAuth support into ATProtoKit. The instructions are a bit complicated for me right now, but hopefully it won't be for you.
I should make a word of caution: once you do get it to work, I have to say that the simplest version doesn't keep users logged in indefinitely. That is, it keeps users logged it for a few weeks at a time, forcing users to re-login. I know that this is a sore spot for users of other third-party applications so please keep that in mind. There's a way to make this longer but it either requires the user to either use their own PDS or for you to have a dedicated server: both of which may not be ideal. This isn't a limitation of ATProtoKit, but of the AT Protocol itself. Once I get my OAuth package ready, I will try my best to document this.
HI Chris, thanks for the update. I appreciate the difficulty of implementing OAuth, which I say without any credible expertise in the protocol at all. I'm not going to try pinning you down on a timeframe, and I don't even think I can say anything about other AT Protocol projects you've been working on, because none of that stuff means anything to me. But without a reliable authentication mechanism, I am in danger of losing users. I'm sure I have lost many who never write to me to complain.
I'm curious about your statement about using OAuthenticator. You're suggesting I use that library to implement the solution against ATProtoKit myself? It sounds like from what you're saying, you've tried it too but found the shelf life of the login was limited? I wonder if you have any additional information that you could share?
[…] and I don't even think I can say anything about other AT Protocol projects you've been working on, because none of that stuff means anything to me.
I understand that and I apologize for giving you irrelevant information. I simply wanted to give you some context of some of the factors behind the slowdown. I will work on eliminating the use of those statements. What matters is that you have a
But without a reliable authentication mechanism, I am in danger of losing users. I'm sure I have lost many who never write to me to complain.
I feel completely guilty over this and this shouldn't have happened. I understand the urgency of this issue. I'm working getting this completed as soon as I can.
I'm curious about your statement about using OAuthenticator. You're suggesting I use that library to implement the solution against ATProtoKit myself?
That is correct. Matt has done a great job at making sure OAuth on the AT Protocol works for his library. You are free to use it, whether as a stopgap while you wait on my OAuth package, or as a permanent solution (your app also offers Mastodon support, which OAuthenticator also provides.
It sounds like from what you're saying, you've tried it too but found the shelf life of the login was limited? I wonder if you have any additional information that you could share?
First, I want to clarify that these limitations are not related to OAuthenticator: these are limits imposed by the AT Protocol, and by extension, Bluesky.
From what I understand, “public clients” (which is what your app would be considered as) has an overall session lifetime of two weeks. There are exceptions to this rule, but they are not irrelevant in your case.
There may be things that I may be off the mark with, but Bluesky has written a blog post about it.
This is something I can’t help with, nor can OAuthenticator can help with and it’s something that many developers have expressed a ton of frustration about. I’m aware of third-party clients that have OAuth enabled and users have complained about the short lifetimes, but the app developer is unable to do much about it. This is why I’m making this warning now: if users do complain about this, then just know that this is an annoying limitation on the end of ATProto.
Hopefully everything makes sense, but let me know if there's any issues with what I've said.
ATOAuthKit's repository is live today.
At the moment, the only child package is the OAuthTypes package. Once the main ATOAuthKit package (which would include the OAuth client) has been implemented (with documentation), this issue will officially be closed.
The goal is to complete the client side before the end of the month.