Authorization and Authentication about crystal HOT 8 CLOSED

@jgmize I actually helped design that system, I'm fairly familiar 😊

I think unifying auth schemes is definitely a long term goal and it wouldn't be too hard. I think the only difference would be the PostgREST claims are set to postgrest.claims.*. I'd like to put it somewhere more general. If someone wants to write up a specification, I'd implement it.

\cc @begriffs @ruslantalpa @diogob

from crystal.

@lfittl yeah, pluggability is a definite design goal (don't want PostGraphQL to be in the auth game too much 😉). I'll leave this open as the a place to discuss how auth will work until a PR gets merged in.

from crystal.

Just opened up a PR containing authorization and a JWT serialization specification at #26. Let's move the discussion there.

from crystal.

Authentication/Authorization I have not put into PostGraphQL but is definitely on my roadmap. The reason it's not done yet is I'm still trying to decide the best way to do auth in GraphQL. I really want to get auth right so we don't have to make breaking changes. Here are my current ideas, tell me what you think:

Authorization

JWTs. The JWT would contain a role field which would be used by PostgreSQL to set the role and other fields would be set as local variables (so say a user_id field in the JWT could be accessed by local_setting('jwt.claims.user_id') in PostgreSQL).

Authentication

There are two phases of authentication in my mind.

1. Do nothing. Since authorization is done via JWT as long as there's a shared secret, the user can issue their own tokens using Auth0, PassportJS, or whatever their heart desires.
2. Add an optional argument to enable a JWT auth scheme that does not use refresh tokens. Such an auth scheme would need a relation (view or table) with three columns user, pass, and role where user would be a unique identifier (like name or email), pass would be the encrypted password, role would be the PostgreSQL role for this user. This relation would be used for issuing tokens. For creating a user, we would insert into this relation user and pass. Extra columns could be specified on the relation for extra claims in the issued JWT. This authentication method must be completely optional and I'm not sure whether it's worth including.

Thoughts?

from crystal.

@calebmer I wonder if it makes sense to make authorization pluggable - in many projects where we've started new services, we initially just read the cookie set by the main app, with some wrapping code to determine the objects one can access using the user_id inside the cookie.

Not saying that this project should support such a mechanism directly, but it'd be helpful if the necessary hooks were provided when you end up building a solution (e.g. using JWT by default).

from crystal.

@calebmer I recommend taking a look at the examples in http://postgrest.com/examples/users/ if you haven't already. I see a lot of parallels between your thinking and what's been implemented there.

If you decided to adopt the same approach, it may even be possible to point both PostGraphQL and PostgREST services at the same db schema and share JWTs between the two APIs.

from crystal.

I think Membership.DB is a good reference for a DB schema, just need to add a column to User for the role.

from crystal.

@tobiasmuehl thanks so much for that link!

from crystal.