How can i trust the token?

Help
,
1

Hello,

I hope you have a bit of patience for some, perhaps, silly questions.

Despite being a software professional several years, i have never been part of setting up auth. This has always been a functioning part of any backend i have worked on.

But now that i am working on a hobby project, it is just me - and i want to get it right.

My (intended) setup:
Web frontend - undefined language, perhaps react, blazor/wasm or razor pages
Backend - One frontend facing api. Perhaps several other services behind that.

I would like the user to be met with a login page if not logged in otherwise presented with the UI.

Since i am a backend dev, i started looking at the api part, and followed this:

It seems to work, and i get rejected as expected. But should there not be something to validate the token that is recieved. Is this really it?
Meaning, if my frontend redirects to a login, and send the resulting token - this would be trustworthy without me doing extra stuff?

I would expect to need to make a call somewhere to ensure the token is valid.

I would also like any other services behind the frontend facing api to be able to double check a token. E.g was it “cancelled” since the request was started.

2

Hi @Toudahl,
Welcome to the Auth0 Community!

Happy to learn that you want to understand what happens behind the scenes :muscle: Looks like you are a classical or pragmatic developer :slightly_smiling_face:

The Quickstart you read is about using ASP.NET Core, which hides a lot of work. The JwtBearer middleware actually validates the access token without requiring any explicit intervention on your side. If you want to learn more about JWT validation in .NET, you can read this article.

I hope this helps.

1 Like
3

Thanks a lot for these resources, they answered my questions. I was having trouble finding what I needed in your vast documentation.

I liked your blog on the different types of developers.
Personally I would say I am flowing between romantic and classical as needed, if I should use your definitions.
I collect the knowledge I need when I need it - if it does not improve the quality/speed of my delivery or help me make the correct choice, then I’m perfectly happy with not knowing.
E.g I have no idea how test frameworks function. And so far, I have not been asked to setup or fix auth - so basic knowledge was enough.
But now I need to know. :slight_smile:

I have two additional questions:
Are refresh tokens something your sdk handles automatically for the frontend app?

Would it make sense to have a local cache to quickly check if a jwt is valid?
Im sure your backend is highly optimized, but sending a request to auth0 from every single service involved in processing a user request, to check if access was revoked seems wasteful and inefficient.

4

Well, according to that blog post’s definitions, you are a pragmatic developer :slightly_smiling_face:

To answer your questions…

Are refresh tokens something your sdk handles automatically for the frontend app?

I do not have a definitive answer to this question, because… it depends. It depends on the specific programming language/framework and application type.
I mean, if your application is a Razor page or ASP.NET Core MVC application, you can use the Auth0 ASP.NET Core Authentication SDK, which has a fantastic support for refresh tokens. Take a look at this article to see a practical example.
Other SDKs may have slightly different behavior. For exampl,e with JS you can choose how to handle refresh tokens.
For other technologies, such as Blazor WebAssembly, we currently don’t have an SDK, so you should rely on the Microsoft’s OIDC library and write your code.

Would it make sense to have a local cache to quickly check if a jwt is valid?
Im sure your backend is highly optimized, but sending a request to auth0 from every single service involved in processing a user request, to check if access was revoked seems wasteful and inefficient.

Again, it depends.
It depends on the type of token and the type of application.
I assume you mean the access token.
To be rigorous, the client of an API should never analyze the internal content of the access token. Here is why.

On the API side, the validation should happen locally. In ASP.NET Core, the needed keys are automatically cached the first time the API receives an access token from the client. You don’t have to worry about this. The subsequent client requests don’t involve Auth0 for validation.

If your concern is about token revocation instead, you can’t set up any strategy. It’s by design. This is why you should rely on short-lived access tokens and refresh tokens.

I hope I have answered your questions.

1 Like
5

You have, thank you :slight_smile:

1 Like
6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.