Two sources of truth for type of the token

[fuelen]

We can set token type in 2 ways

{:ok, token, claims} = App.Guardian.encode_and_sign(resource, %{}, token_type: "refresh")

and

{:ok, token, claims} = App.Guardian.encode_and_sign(resource, %{"typ" => "refresh"})

but with 1st variant I can't pattern match by "sub" field in subject_for_token/2 function. It seems like I don't need token_type key in options at all.

Could anyone explain this design decision and how to use token types correctly?

[scrogson]

The 3rd argument to encode_and_sign/3 is a Keyword list of options that can be used to override any defaults set in your configuration.

https://github.com/ueberauth/guardian/blob/73b0c3d96985a553c97167ec0757d8885030b1ee/lib/guardian.ex#L84

You might find the documentation for the Jwt token module to be useful: https://github.com/ueberauth/guardian/blob/master/lib/guardian/token/jwt.ex

[fuelen]

But using "typ" key I can override default value too

[Hanspagh]

Since typ is also part of the jwt claims you can also use the claims to set the token type. As I understood it, both options are available because sometimes you have some claims and you want to sign a new token with those claims but a new token type. The options type makes this easy and you don't have to add typ to your already existing claims.

[yordis]

@fuelen is this still an issue for you?