@julian diving into the hard problems of building for the Fediverse at #Fedicon, starting with hilariously talking about how those hard problems look like to average users 😅
-
@julian @benpate @FenTiger @evan I am still unclear about how to separate the resource server from the authentication server when implementing FEP-d8c2. This is an essential criterion of OAuth2 and enables the use of existing OAuth2 servers. However, I have the feeling that FEP-d8c2 blocks this path.
naturzukunft@mastodon.social the assumption here is that the authentication server and the resource server are identical.
I know thisismissem@hachyderm.io has thoughts on this because people will want to use third party authentication like FusionAuth.
I don't have an answer for that yet, but I am of the opinion that we proceed with a proof of concept without an answer for now.
-
Yes, count me in. I've been working on FEP-3b86 "Activity Intents" that is a "lighter weight" process that doesn't trade tokens with my origin server and relies on my home server to do all the work.
Mike, how does all of this relate to FEP-61cf: "The OpenWebAuth Protocol"? Should we keep it in mind as well?
Each process will have unique strengths and weaknesses, so Julian had proposed looking for a way to support multiple connections at the same time.
@benpate @julian I'm not sure OWA is the way forward here; mainly it's a lightweight authentication-only alternative to OAuth, and for FEP-d8c2-style SSO the authorization part - issuing the access_token - is important.
FEP-61cf does describe the "zid" mechanism that can be used to avoid the user having to type their handle in; maybe this will be useful (though it's not without its downsides).
-
@julian @benpate @evan I think FEP-3b86 only really allows for actions that the home server already knows how to carry out; the advantage of FEP-d8c2 is that it allows clients to add functionality of their own; see eg Evan's checkin app, which can post geo-tagged activities even via a server which doesn't natively support them.
-
@julian @thisismissem Currently, this would mean that #rdfpub will not participate in this proof of concept, as https://www.keycloak.org/ does not support FEP-d8c2. I would argue that FEP-d8c2 is not OAuth2 if a server such as keycloak cannot be used.
-
@julian @benpate @FenTiger @evan I am still unclear about how to separate the resource server from the authentication server when implementing FEP-d8c2. This is an essential criterion of OAuth2 and enables the use of existing OAuth2 servers. However, I have the feeling that FEP-d8c2 blocks this path.
@naturzukunft @julian @benpate @evan They can't be entirely separated because the AS has to know how to dereference the client_id.
The Client ID Metadata Documents draft RFC will make it possible to do this without relying on non-OAuth standards on the AS side. I doubt there are many servers that support it right now, though (but I think Rauthy has some degree of support for this).
-
@naturzukunft @julian @benpate @evan They can't be entirely separated because the AS has to know how to dereference the client_id.
The Client ID Metadata Documents draft RFC will make it possible to do this without relying on non-OAuth standards on the AS side. I doubt there are many servers that support it right now, though (but I think Rauthy has some degree of support for this).
-
@naturzukunft @julian @benpate @evan Well, it's always been intended as a toolkit rather than as a "plug and play" server/client that are automatically compatible with one another.
-
@benpate @julian I'm not sure OWA is the way forward here; mainly it's a lightweight authentication-only alternative to OAuth, and for FEP-d8c2-style SSO the authorization part - issuing the access_token - is important.
FEP-61cf does describe the "zid" mechanism that can be used to avoid the user having to type their handle in; maybe this will be useful (though it's not without its downsides).
fentiger@mastodon.social ah you're right I hadn't thought about that.
OWA simply can't do the second part.
-
-
@julian @naturzukunft FEP/d8c2 is poorly designed and the comments on socialhub show this. It's not how OAuth is meant to work.
We should be using Authorization Server Metadata + Rich Authorization Requests for any OAuth implementation for an ActivityPub API.
Scopes would ultimately be pretty minimal, e.g., profile, offline_access (both OIDC), and maybe like manage:keys for updating signing keys; the rest should probably be RARs.
For discovery, if the Actor object advertises an authentication method of OAuth or OIDC, the look for the authorization server URL, discover all OAuth specifics from there.
For clients, you could do dynamic client registration, but it has drawbacks, so I'd recommend Client ID Metadata Documents.
-
@julian @naturzukunft FEP/d8c2 is poorly designed and the comments on socialhub show this. It's not how OAuth is meant to work.
We should be using Authorization Server Metadata + Rich Authorization Requests for any OAuth implementation for an ActivityPub API.
Scopes would ultimately be pretty minimal, e.g., profile, offline_access (both OIDC), and maybe like manage:keys for updating signing keys; the rest should probably be RARs.
For discovery, if the Actor object advertises an authentication method of OAuth or OIDC, the look for the authorization server URL, discover all OAuth specifics from there.
For clients, you could do dynamic client registration, but it has drawbacks, so I'd recommend Client ID Metadata Documents.
thisismissem@hachyderm.io said:
> Authorization Server Metadata + Rich Authorization RequestsIs this detailed out somewhere? I'm not familiar with those concepts currently.
-
@julian those are both RFCs, both are linked or referenced in the d8c2 thread on social hub
-
@julian @naturzukunft @thisismissem i don't think there's any assumption that way.
The one thing that the OAuth FEP assumes is that there's a way for the authorization server to validate the client ID and redirect URI by fetching the client ID.
I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that.
This seems like someone who really wants to use that configuration could take a few minutes to confirm.
-
@julian @benpate @evan I think FEP-3b86 only really allows for actions that the home server already knows how to carry out; the advantage of FEP-d8c2 is that it allows clients to add functionality of their own; see eg Evan's checkin app, which can post geo-tagged activities even via a server which doesn't natively support them.
-
@julian @naturzukunft FEP/d8c2 is poorly designed and the comments on socialhub show this. It's not how OAuth is meant to work.
We should be using Authorization Server Metadata + Rich Authorization Requests for any OAuth implementation for an ActivityPub API.
Scopes would ultimately be pretty minimal, e.g., profile, offline_access (both OIDC), and maybe like manage:keys for updating signing keys; the rest should probably be RARs.
For discovery, if the Actor object advertises an authentication method of OAuth or OIDC, the look for the authorization server URL, discover all OAuth specifics from there.
For clients, you could do dynamic client registration, but it has drawbacks, so I'd recommend Client ID Metadata Documents.
@thisismissem @julian @naturzukunft it does what's necessary to enable the authorization code flow.
I think there's plenty of room for two tracks -- developers who want the complexity of discovery and registration can go your route, when you write it up.
Developers who just want to get the job done can use the simple and functional AP-centric mechanism in the OAuth FEP.
-
@julian @naturzukunft @thisismissem i don't think there's any assumption that way.
The one thing that the OAuth FEP assumes is that there's a way for the authorization server to validate the client ID and redirect URI by fetching the client ID.
I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that.
This seems like someone who really wants to use that configuration could take a few minutes to confirm.
@evan @julian @naturzukunft can keycloak parse a non-standard document to discover client metadata? No.
There were very specific reasons why myself and @aaronpk chose to make Client ID Metadata Documents the way we did: because we reused existing parts of the OAuth specification ecosystem.
Your proposal discards all that prior art in favour of making everything an AP actor.
-
@evan @julian @naturzukunft can keycloak parse a non-standard document to discover client metadata? No.
There were very specific reasons why myself and @aaronpk chose to make Client ID Metadata Documents the way we did: because we reused existing parts of the OAuth specification ecosystem.
Your proposal discards all that prior art in favour of making everything an AP actor.
@evan @julian @naturzukunft @aaronpk can keycloak support Client ID Metadata Documents? Currently not to my knowledge, but it's a lot easier to support because it's effectively the same process as dynamic client registration because the document payload is the same.
-
@thisismissem @julian @naturzukunft it does what's necessary to enable the authorization code flow.
I think there's plenty of room for two tracks -- developers who want the complexity of discovery and registration can go your route, when you write it up.
Developers who just want to get the job done can use the simple and functional AP-centric mechanism in the OAuth FEP.
@evan @julian @naturzukunft OAuth isn't AP-centric, and never will be, that's probably your first error. Most OAuth clients will never need to be AP Actors.
Discovery isn't "complex", it's literally a HTTP request to a well known endpoint for a JSON document.
You can't do OAuth whilst ignoring all the OAuth standards.
-
@julian @naturzukunft @thisismissem i don't think there's any assumption that way.
The one thing that the OAuth FEP assumes is that there's a way for the authorization server to validate the client ID and redirect URI by fetching the client ID.
I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that.
This seems like someone who really wants to use that configuration could take a few minutes to confirm.
@julian @naturzukunft @thisismissem
A cursory search shows that it's possible to implement a new ClientLookupProvider with KeyCloak extension SPIs. It sounds like a fun project to do; I don't get a lot of chance to write Java code.
-
@julian @naturzukunft @thisismissem i don't think there's any assumption that way.
The one thing that the OAuth FEP assumes is that there's a way for the authorization server to validate the client ID and redirect URI by fetching the client ID.
I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that.
This seems like someone who really wants to use that configuration could take a few minutes to confirm.
@evan @julian @thisismissem
"I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that."I don't plan to adapt a standard OAuth2 server to support ActivityPub. I think that if that's necessary, something is fundamentally wrong.
