sknebel / autoauth Goto Github PK

compare to https://indieauth.spec.indieweb.org/#discovery-by-clients

• permanent redirects shouldn't be allowed: you have to know who exactly you are logging in as
• temporary redirects have to be followed

Putting the client_id here and then requiring to verify it means it's not actually useful here, except maybe to fulfill OAuth expectations that there is a client_id, and potentially dangerous if someone uses it instead of discovering the endpoint independently.

I'd tend toward removing it. (or putting the vallue of me in there?)

https://github.com/sknebel/AutoAuth/blob/master/AutoAuth.md#token-request

c.f. https://github.com/aaronpk/automatic-indieauth-example

A lot of this would probably also apply to interactive login to another site (the difference to IndieAuth here being the discovery not from the profile URL, and the other site's token endpoint being involved). Potentially also some overlap with use cases, e.g. a feed reader requiring per-feed confirmation, since subscription likely is interactive. Other use cases?

I'm finally looking into implementing AutoAuth in Publ, and I'm getting quite lost trying to wrap my head around the specification to see which responsible parties send which requests. It would be really helpful to have a complete transcript of an AutoAuth flow. The current spec is pretty close, but for a lot of the steps it isn't obvious who is making the request and to what, and it seems like some steps are missing.

Basically, it'd be great to have a transcript for each step indicated in the flow diagram.

For example,

1. client -> resource

GET https://example.com/resource

HTTP/1.1 200 OK  // or 401 Unauthorized
WWW-Authenticate: Bearer realm="posts" scope="read"
Link: <https://example.org/token>; rel="token_endpoint"

2. client -> user authorization_endpoint

etc.

Not part of the main specification, but important for private feeds and worth documenting.

I see three models:

1. WebSub informs all users about all changes to the feed

When the feed changes, the site triggers a notification to all subscribers. If the feed change is in a private post, it does not include it in the ping, either sending the last public state of the feed or an empty ping (effectively announcing an empty diff). Authorized subscribers would take this as a signal to fetch the feed with authorization attached.

This leaks the fact that something private happened to all subscribers. The hub is not involved in handling private information at all, and thus can safely be external.

• Do all/most hubs allow this? A hub that wants to create the diff itself might reject sending out an empty notification, but at least for non-Atom content I don't think hubs do this.
• How do subscribers handle empty pings? Does it cause them to fetch the page, assuming a "thin ping"? This could be mitigated by separating out authorized subscribers as described below. (WebSub does not know "thin pings", but I think pubsubhubbub did and clients might support them)

2. individual topics for private subscribers with fat pings

The site could give different topic URLs (capability URLs) to private subscribers, and send matching notifications to them. (Compare how the WebSub spec recommends returning different rel=self URLs for different content types. Potentially, fat pings could be used then.

A site could use an integrated hub for private subscribers and still let a public hub handle everyone else.

• The hub here can't fetch the private topic URLs (unless it has special support/is integrated).
• If the capability URL leaks, others can subscribe to it and would receive notifications. This would compromise fat pings. Subscribing applications and hubs would need to take care to not leak this, but hubs developed assuming public feeds might not do this. Integrated hubs could only allow one subscription per topic URL, which could mitigate this when each time a different capability URL is submitted.
• integration with token expiry/revocation is needed: the link between token and capability URL must be maintained, and topics associated with invalid tokens not updated anymore.

3. individual topics for private subscribers with thin pings

Compared to 1, it at keeps activity private and solves the issue mentioned above of subscribers potentially fetching needlessly. Compared to 3, it removes complexity, trust in the hub and leaking the cability URL is less problematic, but requires feed fetches on notification.

conclusion

I think 2. is too much complexity. I think it makes sense to document 3., and potentially 1. as an easier option. Testing how it works with existing clients and hubs is needed.

Thoughts/comments?

(Originally published at: https://www.svenknebel.de/posts/2018/12/6/)

Right now it repeats a bunch of information, this maybe should be reduced?

If it is willing to grant the token as requested, it generates a token and sends it to the Callback URL using a POST request. Its parameters are:

• access_token - the token
• token_type: Bearer
• scope - the scopes for which the token was granted (space-separated list)
• base_uri - the base URI defining the protection space
• realm - the realm if any
• state - the state as submitted by the authorization endpoint in the token request

base_uri and realm can probably be removed(?). In IndieAuth, scope is included in the response, does it make sense here?

access_token, token_type and state are definitively staying.

At this point in the spec: https://github.com/sknebel/AutoAuth/blob/master/AutoAuth.md#authorization-code-verification-request

There seem to be two errors, relative to what IndieAuth providers expect:

• callback_url should be redirect_uri
• client_id is required

This is at least the case on all of the IndieAuth endpoints I've tried against (namely SelfAuth and commentpara.de).

Should the Auth Endpoint be able to request a limited TTL?

It can force a limited TTL by triggering token revocation at the right time, but then it isn't transparent to the other actors.

At IWC Åmål, we discussed some questions I had after trying to implement a token endpoint for ‘normal’ IndieAuth and AutoAuth. One of my questions was about the two calls that are made by the token endpoint to the auth endpoint, which differ greatly for both the flows.

For the normal flow, one would send code, client_id and redirect_uri to the auth endpoint associated with the owner of the token endpoint. For AutoAuth, one would send code, root_uri, realm, scope and callback_url to the auth endpoint associated with the user that tries to access the resource (eg. feed). These two sets only have code in common.

This does not have to be a problem, but I asked why it was. The point is that the auth endpoints belong to different parties, thus having different trust relationships between the token endpoint and the auth endpoints.

It also made us question whether or not the token endpoint of AutoAuth is or should be the same as the token endpoint for regular IndieAuth, as they play different roles. @Zegnat pointed out that a big part of there role is one-on-one the same, and that it was nice to have one database of all tokens. I on the other hand pointed out that I would like to separate the database with tokens that point to me vs tokens that point to anyone who tried logging into my site. @sknebel wanted to think more about the matter, hence this issue.

Could it be that this token endpoint is a different endpoint (which is advertised on the resources they apply to, rather than the homepage of the user) and should it have a different rel-value then too? Or should there really be one endpoint?

Right now, details about the token requested is passed in the Token Request, and then sent to the Authorization endpoint to confirm.

Alternatively, it could not be passed there, and only returned in the response to the Authorization Code Verification request, similar to how IndieAuth includes the scopes in the response in the authorization flow.

From some implementer feedback I got, this difference is somewhat confusing, data is passed around more than it maybe has to, and the benefit is unclear.

I think I had some thoughts about making attacks on the auth code harder initially when choosing this, but I think those don't actually apply here.

Right now, the only benefit I could see is some level of validation, e.g. being able to reject clearly invalid requests (with some caveats described in the spec), but that doesn't seem to be a big scenario. Requests that can safely be rejected early will probably be of a type that could only be created through error cases and shouldn't appear often enough to justify special consideration.

Should we switch to the second model, only passing minimal data (maybe the code and me) in the Token Request?

provide examples of error responses and explicitly list OAuth 2.0 error names and their meanings.

An example for how to do this could be the Oauth 2.0 Device Flow (thanks @sebsel for the pointer to that)

• private feeds
• private webmentions
• ...

I’m pretty interested in AutoAuth for a thing I want to build but I feel like it doesn’t quite get what’s needed for feeds (Atom in particular). Atom feeds are often served up through a CDN-type proxy such as FeedBurner or through a translating WebSub proxy like Superfeedr, which makes header-only access control not robust enough.

I feel like there should be an allowance for a link tag with appropriate rel attributes to specify where to receive additional content that would be authorized, both at a feed and an item level. This would particularly help with the WebSub use case, where the push server is only sending the changed entries to the reader, and the reader may have multiple subscribers attached to it with differing access levels.

I’ve been sort of working on some very rough proposals for authenticated feeds in an Atom and WebSub context over at https://beesbuzz.biz/blog/4594-The-authenticated-Atom-musings-continue and while that is far from finalized (in particular I’m leaning towards making all those attributes <link rel>s so it doesn’t need a new XML namespace and can also work with RSS and h-feed) it feels like it runs counter to purely header-based auth negotiation, especially in the WebSub case.

There’s probably something I’ve missed though!

I'm considering writing up some suggestions for using AutoAuth in combination with Webmentions.

As far as I remember, previous attempts at private webmentions included an additional parameter in the request (e.g. a short-lived token). AutoAuth does not need this, but would it make sense to add one?

• + mentions to endpoints that do not support it could immediately be rejected
• ? does it help implementers to make sure to separate private from public responses?
• - it's not needed, and thus adds another possible point of confusion and complexity thats not needed

The access code validation and the requests for later callbacks currently have no response specified, only that it is supposed to be a HTTP 200 (in contrast to an error code). Is this acceptable, or should specific responses be specified?