capjamesgI'm building a search engine for my blog (https://search.jamesg.blog). The engine functions as intended except for one feature I'd like to add: image search that lets you see images.
ZegnatIf you now request my homepage with an authorization token, my display photo should swap out for a picture I just took before :D I wanted to do this to show of my new hair colour, but I need much better lighting :(
sknebelrealistically I shouldn't use this code because whoever wrote it was an idiot who wrote hard to understand code I'm not actually sure it does it right
Zegnatticket is pretty much the same as code, but with grant_type authroization_code the spec requires e.g. redirect_uri to be set. So I think really the only reason for ticket is to use a different grant_type and being able to separate the two paths that led to a valid token
ZegnatI was just thinking because it does not follow some of the security considerations of token intropection, which is basically the same thing but a separate OAuth extension
aaronpkso for Aperture to support the OAuth token introspection spec, I would need to create an additional setup step for people to enter some sort of credentials from their token endpoint into Aperture so that it could make authorized introspection requests
ZegnatAlso re refresh discussions, about maybe putting expiration time in the token verification response. I just feel like there is a risk where a fuzzy line is crossed and we might leak too much token information public.
ZegnatBut maybe not that big a concern. I was just wondering if it could go the way of other older features and be dropped from indieauth if nobody is using it (all introspection happens proprietary behind the scenes) and we could just point at the introspection spec for interop
[fluffy]My tickets/tokens are a signed content blob (using ItsDangerous), and only contain the identity, the scope, and the expiration. All other access information is purely managed server-side.
[fluffy]Eventually I want to add the option to make pure-server-side token storage to Publ, it’s just that I have an underlying design decision that Publ should be as stateless as possible.
[fluffy]I did eventually add an abstraction to Authl to allow stateful token storage as a configuration thing and I plan on putting that in Publ too. And Publ can use stateful sessions since that’s a standard Flask feature, but tokens use a different mechanism.
[fluffy]Publ tokens basically reimplement Flask sessions the long way around, which is annoying but I couldn’t figure out how to use Flask’s built-in stuff without committing some major layer violations.
GWGI just added the code to delete tokens from my external token store when expired, only allow the user who owns the store to retrieve tokens from it, and if there's a refresh token, to try to redeem it on expiry.
[fluffy]The way I implemented refresh tokens, once the original token expires, so has the refresh token. Is the general guidance that the consumer should refresh before expiration, or that the producer should provide some leeway?
[fluffy]I was taking my intuition from how WebSub refresh tokens work, where it’s up to the consumer to refresh before it expires, rather than up to the producer to honor a refresh token that’s already expired.
aaronpkso you might say "I am authorizing this micropub client to create posts on my website indefinitely" but you might not want access tokens to last forever
[fluffy]like the way things stand in Publ, when you get a token, the access token will have an expiration of, say, 1 month, and the refresh token will also have an expiration of 1 month, and you can use the refresh token to acquire a new access token before the access token expires.
[fluffy]Given that refresh tokens don’t even exist in the indieauth spec right now, I feel comfortable waiting for use cases and semantics to be settled better 🙂
ZegnatI would need to check up on WebSub. It feels a little weird to me. Intuitively I would be using an access token all the time, until I hit a 4xx with it, then I will dig up the refresh token to get myself a new one. If the refresh token then fails, I need to go request authorization from scratch.
[fluffy]In websub, the lease_seconds just tells you how long the subscription will stay active, as guidance to the consumer for when to initiate a new subscription request. There’s no such thing as a refresh token in it.
[fluffy]like as someone who’s implementing indieauth directly but gives approximately zero craps about the underlying OAuth it’d be nice for the section to at least call out the “see more” from the original spec.
[fluffy]Anyway I think that if the IndieAuth spec on token grants were to point to the OAuth spec on token grants with language like “IndieAuth tokens also support token refresh per [the OAuth spec](blahblahblah)” that’d be satisfactory to me. I had no idea refresh tokens were even an option until GWG opened the issue.
[fluffy]Supporting Micropub in Publ is gonna be weird because Micropub uses a token grant from the IndieAuth provider, but Publ isn’t actually integrated with the provider. Like I use SelfAuth to log in to my own Publ instance.
ZegnatI think nothing in Micropub requires IndieAuth. It just mentions IndieAuth as a way to obtain a token, and that is what most (all?) Micropub clients now require.
aaronpkcorrect, indieauth is a way to get an access token, ticket auth is a way to get an access token, and you could also get an access token using oauth core, or the oauth device flow, etc
[fluffy]Are there any clients which would be amenable to a flow other than “sign in with indieauth, then use that same site’s token_endpoint to get a token from the indieauth instance”
[fluffy]like there’s probably some major disconnect that I’m not understanding here but on my site the authorization_endpoint points to SelfAuth but the token_endpoint points to Publ, and Publ knows nothing about how SelfAuth validates an identity.
[fluffy]but I’m thinking that Publ *could* go “okay this thing is asking for an access_token against this identity with this authorization code, I’ll look up that identity’s authorization_endpoint and token_endpoint and use that to validate the code”
[fluffy]but this has all been a low priority for me anyway since I don’t personally care about using micropub to post to my site. I’d love to support micropub so that other people have less friction in using Publ though.
ZegnatIt is definitely a balancing act of wants and needs et al. IndieAuth is an extension to OAuth for letting unregistered clients discover the correct OAuth endpoints to be able to request tokens. So if you want to support IndieAuth as a way for clients to request tokens, the must be a way for the authorization_endpoint and the token_endpoint to speak to eachother.
[fluffy]One reason why I don’t want to integrate the IndieAuth authorization_endpoint into Publ is that Publ itself is just the site publishing engine, and it’s not necessarily going to be for a single-author site. Like one specific reason I do want to support Micropub is to allow a community blog sort of thing. I’m not sure if that’s compatible with how Micropub clients expect identity to work though.
[fluffy][aaronpk] yeah but I mean like… don’t micropub clients all at least assume that you’re going to be signing in as the identity of the site itself? Or if not, that’s probably where my massive disconnect lies.
aaronpkno not really, the micropub client doesn't really care what identity you're signing in as, because it's not trying to know *who* you are, it's trying to get an access token to be able to create posts at the micropub endpoint
[fluffy]okay but that’s still where there’s a weird little edge case in supporting Micropub on Publ… let me try to flesh out an explanation of why this is weird to me
aaronpkin practice, some micropub clients will show the "me" URL to show the user which site they are posting to, but that URL could be a user-specific URL on the site, or could be the site's home page, it doesn't really matter
ZegnatMost (all?) Micropub clients use IndieAuth to discover the authorization_endpoint, but that is just the place they send their user to authorize a token. sink.zegnat.net for instance will let users write in their own site address and do IndieAuth with their own setup rather than relying on an identity issued by sink.zegnat.net itself
[fluffy]If someone tries to post to beesbuzz.biz, they’d be asking beesbuzz.biz’s token_endpoint for an access token to post to it, right? And that token has to go through some sort of authentication flow to make sure that the token is valid, which it would do presumably by asking that someone’s IndieAuth endpoint.
[fluffy]And that’s all well and good with how things are set up… but then if *I* try to post to beesbuzz.biz, my IndieAuth identity (validated by SelfAuth) is also beesbuzz.biz, and so my token_endpoint would appear to be publ’s, not SelfAuth’s
ZegnatYou probably only want to trust tokens from publ’s own token endpoint for micropub requests to publ. Trusting tokens created by external token endpoints might be risky, as they can claim to be for any value of `me`. So you need impersenation checks etc.
aaronpkthis is why there was originally a part in the indieauth spec that described how the two endpoints can talk to each other, which is how tokens.indieauth.com works
ZegnatI would expect to point a Micropub client at a Publ site, end up on a login page provided by Publ (the authorization_endpoint), when I login there (proofing my identity in some way to Publ) I will be redirected back to the Micropub client with a code. The Micropub client then exchanges the code against Publ‘s token_endpoint to get a token to send along with Micropub requests.
aaronpkso if you want to continue down the path of completely separate and interoperable token and authorization endpoints, you'll need a contract between the two, which we've moved out of the core indieauth spec but could be done as an extension
aaronpkpersonally i am not interested in continuing to support tokens.indieauth.com or that model, so i have no interest in that extension, but that's not to say someone else couldn't take it and run with it
[fluffy]IIRC the tokens.indieauth.com approach isn’t workable either though, and I’m having too much difficulty articulating it and should probably give up again before I get frustrated and another giant pain flare from this
ZegnatI guess I do not understand why publ can’t support a login box at the authorization_endpoint. Which is all it would need to be able to issue tokens
[fluffy]but anyway the tl;dr of the problem as I see it is that beesbuzz.biz-as-identity is different than beesbuzz.biz-as-resource as far as what the token_endpoint should be
[fluffy]if publ provides an authorization_endpoint that then lets people proxy a login to their own identity then anyone can just log in as me if they’re able to log in to my site.
aaronpkif you want other users to sign in to beesbuzz.biz, that site would be acting as an indieauth *client* and would go discover the authorization endpoint of the user
[fluffy]but like. beesbuzz.biz lets people sign in using indieauth (among other things) as an indieauth client, but it also provides an authorization_endpoint that lets me sign in to other things.
ZegnatAah. Hmm. I see now. You would want authorization_endpoint both to be your Selfauth instance because you want to use beesbuzz.biz as your identity. But for the IndieAuth multi-user workflow you would also want the authorization_endpoint to point at the external-user login form.
ZegnatSo sink.zegnat.net is a group blog in that way. So its authorization_endpoint is actually an IndieAuth login page and lets anyone login. Then when they are logged in the sink.zegnat.net token_endpoint can issue a token matching their identity (because they have proven who they are). But that obviously would not work if the sink.zegnat.net authorization_endpoint was also the thing I personally wanted to use to proof my own identity.
[fluffy]okay so I’m thinking, then, that the authorization_endpoint on a group blog could even just point to an Authl signin page and people could therefore use non-IndieAuth identities to sign in for this
[fluffy]There’s still the issue that like… if a group blog has an authorization_endpoint that accepts any login to it, then theoretically *anyone* could use that group blog to identify to another site (even if they aren’t granted post access to that group blog)
aaronpkthe authorization endpoint is the one that decides what "me" URL to send back to the client, and it can use whatever criteria it wants to make that decision
[fluffy]yeah but then that gets back to the problem of requiring people to have a means of signing in to their author page identity which may or may not be IndieAuth. I suppose that could b epushed down a layer and the author profile can have a list of allowed third-party identities.
[fluffy]in the case of Publ I was definitely going to be making the Micropub stuff in a separate library that would only be optionally pulled in so that means this doesn’t have to complicate Publ itself. and it can provide a route like /_author/<name> which provides their h-card and whatever, and is configured at an admin level such that <name> maps to third-party identities.
[fluffy]the ticket issuer isn’t going to do anything based on what the ticket endpoint replies with, and 200/202/whatever and fun message seems :thumbsup: to me
aaronpkmy assumption is that either everything is bundled into a single piece of software (e.g. wordpress with a built in reader), or all authorization stuff is a standalone thing that is used by all the various parts
GWGBut [fluffy]'s thought makes sense. If the ticket endpoint is integrated with the Microsub endpoint. I've been integrating mine with my token and auth endpoint code.
[fluffy]I’ve been sort of avoiding thinking about the webmention side of things because I feel like mixing webmention and private content is inherently risky
aaronpki think i am going to add an endpoint to my new app so that my website can ask "do you have an access token that might work at X resource", that way it could be used for feed fetching as well as webmention
[fluffy]I keep meaning to add bearer token support to Pushl but it was going to be based on sideband token grants, rather than trying to use anything like ticketauth etc., but then the whole mention verification thing becomes difficult, etc.etc.
[fluffy]like if I have a private post that links to another private post, Pushl needs to be able to see the source post, it needs to be able to get the mention endpoint of the target post, and the mention endpoint needs to be able to see the source post.
GWGI may, after this is more stable, contemplate the idea of a second POST request to the ticket endpoint, with a required bearer token from my token endpoint, scoped to allow it to return the token in question.
[fluffy]and even if all that stuff does work, in the common case you potentially have a public post that’s replying to a private post and then that causes drama/privacy violations/etc.
[fluffy]It’s really annoying when people post a public tweet in response to my private post stubs. So far there hasn’t been anything particularly awful from that, just the occasional “Oh, I’m sorry” in response to a “Private post: [akjdflkajsf]” tweet.
Zegnataaronpk: what sort of endpoint do you mean? You mean that Aperture could go to aaronpk.com and ask "is there a token for subject aaronpk.com at resource vanderven.se that I can use for fetching?"
ZegnatThat is pretty close to the autoauth case, yeah. Probably with the difference that for autoauth, you would make that request, and then that endpoint goes of to the mentioned resource to see if it can request a token in your name
batkin[m]Going back to something I was trying to figure out several weeks ago - I'm wondering how to make it so I could enter any-subdomain.benatkin.com into a micropub client, and have it use the identity benatkin.com.
sknebel"so that when aperture is fetching your home page for me, it could include an access token that you have sent me" - that's what autoauth had requests and extra scopes for
ZegnatIt is really just a question of interop/standardisation for all those steps. And the question whether it even all belongs in the same spec or not. Ie. does it belong in TicketAuth or separate? Can it only work by having one huge sped like Autoauth? etc.
GWGsknebel: In theory, if we wanted an external API, it could be a token scoped with a token requesting scope, that posted to the ticket endpoint to get back tokens.
ZegnatYou should be storing the resource values from the first ticket request for that, surely? That is what it says "these resources should accept the token"
ZegnatI am trying to figure out if there is some sort of attack possible through multi resources, if we only ever check the first resource to find the token-endpoint, but would end up sending the token for requests to the second resource as well. Recourse 1 and 2 might be on different origins
GWGLet's say I send you a ticket that has a page on my site that delivers Zegnat's token endpoint. When I try to redeem the ticket, it will fail. How could that be an issue?
batkin[m]When trying to use micropub with a subdomain, and logging in with Quill, I got "The domain for the user returned did not match the domain of the user initially signing in"
sknebelthinking about it a bit more, I feel like "path below the resource" (or maybe even same origin) + "advertises the same token endpoint" works as "is this token usable here" best
Zegnataaronpk: OAuth question, I am looking at RFC 7009 (revocation) for security considerations, to see if I am implementing it right. And the following confuses me: "According to this specification, a client's request must contain a valid client_id, in the case of a public client". I cannot find an example in the spec on how it expects public clients to send their client_id along with the revocation request. Nor does IndieAuth hint at it
aaronpkthe notes in the security consideration make sense though, you don't really gain any security by checking for the client_id for public clients since there's way worse things you can do if you are malicious and have the token
sknebel(i.e. my mental model would be "sure, send the client_id, server might log it etc", but not "require a known client_id to accept a revocation request"
ZegnatBut the way some of it reads, it seems it only wants me to allow revokes if you know the matching client_id? Which then feels counterintuitive to me
aaronpkusually these kinds of extra parameters that feel unnecessary at first are there to prevent mixup attacks of various sorts, but there isn't anything to mix up in this spec
ZegnatI would even say the oposite is true for this spec, aaronpk :D If you somehow got a random token that is valid for a private resource, I would lovev it for you to revoke it ;)
sknebelthat reminds me, I found this video snippet about "how the web works" from a German kids TV series again a while back (I can remember seeing the original episode!): https://www.youtube.com/watch?v=fpqhjEtznVk
ZegnatReading the iss draft now, those mix-up attacks were what I was thinking of wrt having multiple resources specified when sending a ticket. Trying to trick a client to leak its token to a resource I control. Just could not actually come up with a scenario that would sufficiently trick a client
capjamesg I'm building a search engine for my blog (https://search.jamesg.blog). The engine functions as intended except for one feature I'd like to add: image search that lets you see images.
Loqi search in the context of the IndieWeb refers to being able to search your personal site for your own content https://indieweb.org/search
[snarfed] I’ll just leave this here for create day: https://bridgy.readthedocs.io/#adding-a-new-silo
GWG aaronpk: You can discover it at https://wpdev.gwg.us
[KevinMarks] what shoudl I read to understand the ticket thing you're all making?
Zegnat I am using https://addons.mozilla.org/en-GB/firefox/addon/modheader-firefox/ to manually add an Authorization header while browsing.
[fluffy] Anyway I think that if the IndieAuth spec on token grants were to point to the OAuth spec on token grants with language like “IndieAuth tokens also support token refresh per [the OAuth spec](blahblahblah)” that’d be satisfactory to me. I had no idea refresh tokens were even an option until GWG opened the issue.
aaronpk i did write most of ticket auth too but this was the first draft 😂 https://indieweb.org/wiki/index.php?title=IndieAuth_Ticket_Auth&oldid=70851