AutoAuth (working title) is a draft for an extension to IndieAuth for authorization without the user being present, e.g. for reader applications following private feeds.
The current draft can be found in AutoAuth.md, feedback very welcome!
AutoAuth is a WIP extension for IndieAuth without the user being present
AutoAuth (working title) is a draft for an extension to IndieAuth for authorization without the user being present, e.g. for reader applications following private feeds.
The current draft can be found in AutoAuth.md, feedback very welcome!
An example for how to do this could be the Oauth 2.0 Device Flow (thanks @sebsel for the pointer to that)
compare to https://indieauth.spec.indieweb.org/#discovery-by-clients
provide examples of error responses and explicitly list OAuth 2.0 error names and their meanings.
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?
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
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.
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!
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?
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 requiredThis is at least the case on all of the IndieAuth endpoints I've tried against (namely SelfAuth and commentpara.de).
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.
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?
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?
Not part of the main specification, but important for private feeds and worth documenting.
I see three models:
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.
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.
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.
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/)
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 neededShould 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.