@Auth variable from header value not from header JWT

Hi

I am wondering if I can get an @auth query to use a variable that isn’t decoded from a JWT rather just directly from a request header key value pair?

In context I have a web assembly SPA app (running completely in the browser) which is using a third party for authentication from which I get some context on the user back such as a unique key, email, profile information etc…

The whole solution is running on SSL so I am hoping not to have to run up an api server just to generate a JWT to pass variables into the slashgraph auth model for it to be decoded again - I would prefer just to add the variables to the http header.

I mocked the auth rule with a string for the email and verified in principle it works

type consultancy @auth(
query:{rule:"query{queryconsultancy { ACL { user(filter: {email: {eq: \"name@domain.co.uk\"}}) { email } } }}"}
){
 id:ID!
 name:String!
  ACL:[ACL]!
}

but if I add a request header with the key: email and value: name@domain.co.uk and then adjust the auth query as

query:{rule:"query($EMAIL: String!){queryconsultancy { ACL { user(filter: {email: {eq: $EMAIL}}) { email } } }}"}

I get a network error - I assume as it has nothing in the schema to try and decode the header against (given it is not encoded in the first place)

If i exclude the request header then the query runs appropriately and returns nothing which is the expected behaviour.

is this not possible or am i doing something wrong?

Thanks

The authorization directive expects to get the information from JWT. It won’t work if the EMAIL is passed using HTTP headers.

Even this rule will expect the EMAIL variable to be provided using JWT.

If you are okay with passing email (without any auth mechanism) through HTTP headers, you may also consider adding filters (instead of using auth) to the query. This can ensure that information for the user with specified email is fetched.

Although, the big drawback is that this is not secure, It will mean that anyone with an email of a user can use filter query to fetch the user’s information.

Thanks Rajas

That makes sense.

I have now managed to aquire JWT tokens from my auth provider OKTA and have now come across another stumbling block… All of the claims seem to be in the root of the payload as opposed to within a namespace.

{
  "sub": "xxxxxxxxxxxxxxxxxxx",
  "ver": 1,
  "iss": "https://abc-1234567.okta.com/oauth2/default",
  "aud": "xxxxxxxxxxxxxxxxxxx",
  "iat": 1609590699,
  "exp": 1609594299,
  "jti": "ID.xxxxxxxxxxxxxxxxxxx",
  "amr": [
    "pwd"
  ],
  "idp": "xxxxxxxxxxxxxxxxxxx",
  "nonce": "nonce",
  "auth_time": 1000,
  "CustomClaim1": "xxxxxxxxxxxxxxxxxxx",
  "CustomClaim2": "xxxxxxxxxxxxxxxxxxx"
}

Not like…

{
  "sub": "xxxxxxxxxxxxxxxxxxx",
  "ver": 1,
  "iss": "https://abc-1234567.okta.com/oauth2/default",
  "aud": "xxxxxxxxxxxxxxxxxxx",
  "iat": 1609590699,
  "exp": 1609594299,
  "jti": "ID.xxxxxxxxxxxxxxxxxxx",
  "amr": [
    "pwd"
  ],
  "idp": "xxxxxxxxxxxxxxxxxxx",
  "nonce": "nonce",
  "auth_time": 1000,
  "Namespace": {
     "CustomClaim1": "xxxxxxxxxxxxxxxxxxx",
     "CustomClaim2": "xxxxxxxxxxxxxxxxxxx"
  }
}

Is there any way to use CustomClaim1 and CustomClaim2 from the root of the payload as in the first example (i.e. effectively a namespace of “”)?

I have the inverse question on Okta’s forum asking how to generate a namespace for custom claims too!

Follow this post

That sounds like a great way forward.

In terms of implementation do you have any thoughts on a timeline?

@pawan could answer if the core devs are working on this, but I believe @dan-j is working on a PR for this as a community member.

Cheers @verneleem just realised from your profile you weren’t one of the core team! thanks have commented in the post you shared. Really appreciate you noticing this.

1 Like