Repository navigation
Extension to Allow Clients to Get Tokens Secured by Ticket #88
Description
Want to start discussing this.
Proposing a simplified way for a client to get access to the token secured by the ticket endpoint. Starting with the autoauth solution, suggest that the client, in a user initiated interaction, needs to secure a token with a scope that gives it permission to retrieve tokens, let's say scope 'external_token'. We already have a flow for this, so no changes are required.
So, using the example of a social reader application, when you configure it, you grant it, or don't grant it permission to retrieve external tokens.
Then, the client would use that token, with the scope, to request it be given a copy of the stored token. That would likely be at the token endpoint for the user they are obtaining it on behalf of, with a new grant_type, providing the token that authorizes them to get these tokens, the client_id of the client requesting it, and the resource the URL the token allows access for.
Just started thinking about this, so a bit rough.
Activity
dshanske commentedon Aug 18, 2021
@Zegnat commented that overloading the token endpoint might not be the best idea, and having a query to the ticket endpoint with the previously mentioned bearer token might be better
dshanske commentedon Aug 29, 2021
If we end up querying the ticket endpoint, then it would have to be another POST request, with a bearer token with the 'external_token' scope in the Authorization header, with the resource URL, and it would either return the access token it previously got or error.
Or alternatively, to match the syntax of token introspection, it could be a POST request with the token supporting the external_token scope in the body instead? For example, token=xxxxxx&resource=https://example.com with the response format being equivalent to the IndieAuth access token response, with the added elements of resource
dshanske commentedon Sep 24, 2021
Actually, looking, token introspection uses aud, not resource. Too many changing parameter names.
dshanske commentedon Sep 24, 2021
By using the token introspection language, we mirror what we're introducing into the token endpoint, and it ends up being a similar flow to implement. But, debating the POST formatting. Which makes more sense?
Also, looking at the discussion on the refresh_token flow, @aaronpk pointed out that client_id is a mandatory parameter in that flow, even though it should be associated with the token already, for various reasons. So that would suggest in this context, subject should be a mandatory parameter. Client_id probably should as well, because the client would be issued a token giving it scope to request these tokens stored in the ticket endpoint.
Decisions, decisions...
dshanske commentedon Oct 2, 2021
Wonder if the flow for getting an introspection token #99 should match the proposed flow for getting a token to retrieve external tokens.