Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injecting more claims into operations inputs #5

Open
Twathik opened this issue Mar 19, 2022 · 3 comments
Open

Injecting more claims into operations inputs #5

Twathik opened this issue Mar 19, 2022 · 3 comments

Comments

@Twathik
Copy link

Twathik commented Mar 19, 2022

hello

I was trying WG fro a while now, I'm using keycloak as open id server, in keycloak we can specify custom claims and roles

for now we can inject some claims into operations, this will be very useful if we can extend the list of the current claims that we can inject in operations to all claims provided by open id, or even custom one,

I dont know if this will be possible regarding typing in graphql schemas

for exp keycloak user_id, first_name, last_name etc ..

as for exp

authProviders.openIdConnect({
    id: "keycloak", // you have to choose this ID
    clientId: "client-id", // client ID from Auth0
    clientSecret: process.env.client_secret || "", // client secret from Auth0
    issuer: "http://keycloak.local/auth/realms/Realm",
    claims : ["email", "first_name", "last_name", "user_id", "roles" ... ]
  }),

this claims can be used by the code generators to be available in the custom directive

@jensneuse
Copy link
Member

Do you have an example Query where you'd use a role claim?

@Twathik
Copy link
Author

Twathik commented Mar 20, 2022

mutation (
  $email: String! @fromClaim(name: EMAIL)
  $roles: String[] @fromClaims(name: ROLES)
  $userId: String!
  $name: String!
  $lastName: String!
  $firstName: String!
) {
  usersDb_createOneUser(
    data: {
      email: $email
      roles: $roles
      userId: $userId
      name: $name
      lastName: $lastName
      firstName: $firstName
    }
  ) {
    id
  }
}

To persiste roles into the database,

This is only relevant when introspecting databases, as it is possible to implement this on the microservice it self, or in the post auth hook

All things considered, with a little workaround we can manage to persiste anyway

Thx for the replay

@jensneuse
Copy link
Member

Is roles always an array of strings? What if not?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants