Pass data via Token Request vs Authorization Code Verification response?

[sknebel]

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?

[sknebel]

@gregorlove @mblaney I know it's been a while since you did an AutoAuth implementation, but I wonder if you have any ideas on this issue and potentially #17

[mblaney]

hi @sknebel, I'm not sure about the minimal version, would we at least need a state parameter to verify we initiated the request? In the demo I was pretty happy that I didn't have to touch my authorization endpoint code at all, it just worked with AutoAuth as it was. I haven't done enough work on this yet though so open to ideas on how to improve it.

[sknebel]

Yes, state would be needed.

You implemented the reader side, right? That already needed some small changes for AutoAuth in die authorization endpoint: https://github.com/sknebel/AutoAuth/blob/master/AutoAuth.md#authorization-code-verification-request - note how here lots of parameters are sent to the Auth endpoint - whereas for comparison normal IndieAuth takes minimal parameters and responds with the data: https://indieauth.spec.indieweb.org/#authorization-code-verification-0

[gRegorLove]

I'll need to refresh my memory on the whole process, but at an initial glance, I think the client_id would also be required in a minimal token request, since that's part of the verification process. Or is there an alternative, safe way around the me === client_id check? Is it not needed?

[mblaney]

hi @gRegorLove client_id is the authorization endpoint here, so you could look that up from the me url .

@sknebel yes I did the reader side, and our demo was very minimal all I did from the authorization endpoint was return me if presented with a valid code. The question is, to do a more complete demo how many parameters really need to be checked by the authorization endpoint?

[gRegorLove]

@mblaney I wasn't sure if doing it that way is a security risk. I can't think of an attack offhand, but I figured that client_id/authorization_endpoint verification had some prior art. It appears it's been there since the original session.

Edit 2: It appears to come from https://tools.ietf.org/html/rfc6749#section-3.2.1

Edit 1: I mis-typed before, it's not client_id === me, but client_id === me's authorization_endpoint

[fluffy-critter]

re https://chat.indieweb.org/dev/2019-10-30#t1572460599325500

My use case is having a single token granting endpoint that I can use for all permission grants, both in the IndieAuth and AutoAuth flows. In particular, I am authorizing users for access to resources at the time of resource request, based on the user's identity and scope that are associated with the token.

One possible use case of this is having a shared blog which can have multiple authors who submit posts directly via MicroPub (or similar).

It seems to me that a single token granting endpoint could cover both the first-party and third-party authorization cases, and the important thing is simply ensuring that both token grants have the necessary parameters sent through on the code verification request.

Conceivably it should be reasonable for a token endpoint to simply pass all of the POST parameters along to the GET on the code verification, although this opens up the possibility of the token endpoint being used as part of a reflection/amplification attack on an unrelated web service, so I would prefer to err on the side of whitelisting the necessary parameters. But then that opens up the possibility that some future extension to these protocols (or another as-yet unimagined authorization flow) might need some additional set of parameters to be sent through, which would slow down adoption considerably as the number of implementations grows.