In #166, Lastuser introduced automatic scope for trusted clients (apps hosted on the same parent domain as Lastuser itself, or apps hosted by the same company, ie, HasGeek). That ticket discussed eliminating auth tokens entirely for trusted apps, but did not implement it.
We're now considering removing redundant data storage from client apps. They should no longer need to have User, Team and Profile tables, or at least, they may have these tables for the sake of referential integrity in the database, with a single UUID column that matches Lastuser's record.
In such a scenario, client apps will need to use GraphQL (as per hasgeek/coaster#100 item 4) to populate details from Lastuser. A client may ask for the same fields across many different users (SELECT column, … FROM "user" WHERE id IN (…)) in a single query, which presents a problem when OAuth requires a separate auth token per user, but accepts only one auth token per request.
Since Lastuser already knows which client is authorised to access which user's data, it could just accept client credentials for the GraphQL API and automatically look up auth tokens. This presents a few further issues:
A join with the AuthToken table on every single query will slow down GraphQL.
Since the scope on tokens is not database-parseable (it's an unindexed string that's split along spaces in app-level code), we can't check for valid token scope in the database (unless we risk using LIKE queries or a Postgres-only regex query). It has to be done in app code, either by preloading tokens for requested users, or by filtering after loading data.
We can improve this by redefining scope to be database-parseable, for example by making it a set of independent flag columns for all known Lastuser-provided resources, but the join will still be necessary.
We can add further trust to trusted clients by eliminating the token check entirely. As long as they have automatic scope (#166) that matches the requested data, let them have the data. This breaks one assumption we've retained despite #166 with auth tokens: they represent a fact of a client app being aware of an interested in a particular user. This may not be important if transaction logs can provide the same data.
An untrusted app will still require the database join.
A client app may have additional scope for a particular user than what it normally requests. This is possible in Flask-Lastuser by using the @lastuser.requires_scope decorator. In this case too, automatic scope may deny access while the specific auth token provides it. The token therefore needs to be consulted.
Finally, one other consideration: perhaps any query that presents a user id must also mandatorily provide the auth token (or just the auth token) so that the API doesn't have to special-case all situations where the token is required.
In #166, Lastuser introduced automatic scope for trusted clients (apps hosted on the same parent domain as Lastuser itself, or apps hosted by the same company, ie, HasGeek). That ticket discussed eliminating auth tokens entirely for trusted apps, but did not implement it.
We're now considering removing redundant data storage from client apps. They should no longer need to have User, Team and Profile tables, or at least, they may have these tables for the sake of referential integrity in the database, with a single UUID column that matches Lastuser's record.
In such a scenario, client apps will need to use GraphQL (as per hasgeek/coaster#100 item 4) to populate details from Lastuser. A client may ask for the same fields across many different users (
SELECT column, … FROM "user" WHERE id IN (…)) in a single query, which presents a problem when OAuth requires a separate auth token per user, but accepts only one auth token per request.Since Lastuser already knows which client is authorised to access which user's data, it could just accept client credentials for the GraphQL API and automatically look up auth tokens. This presents a few further issues:
A join with the
AuthTokentable on every single query will slow down GraphQL.Since the
scopeon tokens is not database-parseable (it's an unindexed string that's split along spaces in app-level code), we can't check for valid token scope in the database (unless we risk usingLIKEqueries or a Postgres-only regex query). It has to be done in app code, either by preloading tokens for requested users, or by filtering after loading data.We can improve this by redefining
scopeto be database-parseable, for example by making it a set of independent flag columns for all known Lastuser-provided resources, but the join will still be necessary.We can add further trust to trusted clients by eliminating the token check entirely. As long as they have automatic scope (#166) that matches the requested data, let them have the data. This breaks one assumption we've retained despite #166 with auth tokens: they represent a fact of a client app being aware of an interested in a particular user. This may not be important if transaction logs can provide the same data.
An untrusted app will still require the database join.
A client app may have additional scope for a particular user than what it normally requests. This is possible in Flask-Lastuser by using the
@lastuser.requires_scopedecorator. In this case too, automatic scope may deny access while the specific auth token provides it. The token therefore needs to be consulted.Finally, one other consideration: perhaps any query that presents a user id must also mandatorily provide the auth token (or just the auth token) so that the API doesn't have to special-case all situations where the token is required.