@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 @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.

@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.

@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.

@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 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.

@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.

@naturzukunft @julian @thisismissem that's fine; you should do whatever it is you want.

@naturzukunft @julian @thisismissem oh, are you going to use Keycloak's built in user database, or are you going to use an adapter to fetch user data from your own database?

@naturzukunft @julian @thisismissem oh, are you going to use Keycloak's built in user database, or are you going to use an adapter to fetch user data from your own database?

@evan @julian @thisismissem which user data to do what ?

@naturzukunft @julian @thisismissem oh, sorry. By default, KeyCloak stores all the user data (name, avatar, description, so on) in its own internal PostgreSQL database, and you get an API to ask about and manage users.

The alternative is to add a custom UserStorageProvider class to access your own user storage and map your data to KeyCloak's schema. Applications that already have a user database often do this.

@naturzukunft @julian @thisismissem oh, are you going to use Keycloak's built in user database, or are you going to use an adapter to fetch user data from your own database?

@evan @naturzukunft @julian in the wild it's very uncommon to replace Keycloak's user database with something else; most commonly user migrations are performed, having been involved in several such projects.