Using auth0 outside of React Components

Hey there, I followed along with the React SDK quickstart and I have a couple of questions.

The quickstart guide in part2 makes http requests directly in components, which is nice and easy because auth0 available via context. However I like to wrap API interactions into a service class that is react agnostic to promote separation of concerns for presentation vs infrastructure.

To achieve this whilst maintaining a single auth0 instance I am pulling auth0 out of react context and constructor injecting into my api client.

Further I require a couple of different contexts and at present am constrained by a bunch of class components, so I have ended up writting a couple of HOC’s to pull auth0 and other required context items to pass as props to components that require them.

Whilst i’m a big fan of dependency injection, something feels wrong about my approach.

Questions

  1. Is there a better way to get auth0 out of context and into plain old es6 classes.
  2. Would it be appropriate to have 2 auth0 clients, one for the router guards and another for api wrapper classes
  3. Why is creating the client async, surely it could be constructed sync but all interactions e.g. getTokenSilently async?
2 Likes

This is a great question! I have an application that uses a Reactive Service powered by RxJS and TypeScript to carry out authentication. Would you like to look at that code?

1 Like

Would very much appreciate a look, i’m not sure if that’s similar though, I’m quite happy leaving the sample code carrying out auth, I just want to grab an access_token out to use outside of the react context.

You got it. By chance, do you have a sample or MVP of how you are currently implementing this?

Hey can u send it to me too :slight_smile: tnx in advance

Same here.
I’m executing most of my API calls from MobX stores and don’t have direct access to getAccessTokenSilently.
I need to pass it around all over my app…

1 Like

Hi,

I am just wondering why all the example apps using this approach to always get the token inside the component. For me this seems like quite the anti pattern because it is leading to a lot code duplication.

Is there a specific reason to do it this way?

I am currently struggling to either making my access token available application wide, to get rid of all the duplication or writing kind of an extension to the fetch function that is getting the access token every time and can be reused by all components.

3 Likes

@dan-auth0 @rustybox

I followed The Complete Guide to React User Authentication with Auth0 and everything is working nicely, but I only fetch the access token once when mounting my main App component and I save it in my redux state. Using Redux Thunk and Axios, all my API requests happen from that middleware outside of any React component, reusing the same saved access token.

Now I would like to skip storing the access token and would like to to get it from the Auth0 library every time I make an API call, to make sure I don’t end up with an expired token. I can’t seem to figure out how though, as the getAccessTokenSilently hook can only be used inside a React component that is a child of the Auth0Provider and not from the redux middleware (or basically any other js file).

If I understand correctly, this post is about a similar problem, although I’m not using auth0-spa-js but the newer @auth0/auth0-react library. Can you please share your ideas / solutions on this topic?

Thx!

6 Likes

Howdy, Jente! Welcome to the Auth0 community. I may not be able to write a full blog post on this yet, but I can offer to create a code snippet showing the Auth0 + Redux integration. Would that work for you?

2 Likes

Hi @dan-auth0 ,

That would be great! I already refactored my app to avoid saving the token in redux, but now I always pass the getAccessTokenSilently promise from my components to every method inside my middleware so I’m able to fetch the token there before firing a request to my API. It works fine, but it’s not ideal.

It would for example be great to be able to create an Axios request interceptor from which I can call getAccessTokenSilently and add the token to the header for every request. That would mean no more repeated code and no more passing around the getAccessTokenSilently promise :slightly_smiling_face:

Thanks!

1 Like

Hey @dan-auth0 do you mind sharing this with me as well? I just posted a topic with a similar concern to Jente’s. Thanks in advance!

Thanks for these active forums! I just wanted to +1 @jente.libaers question above-- we are in a very similar situation and would benefit from any thoughts/ideas. Thanks!

@jente.libaers @ncarroll @trevor I have been playing around with one of my demos to integrate Redux. It has TypeScript so this make it a bit more complex – much more with the Redux Toolkit. Lately, I am having a hard time finding a use case for Redux in my apps as I can get mostly everything done with direct calls to the API and using React Context.

When I need Redux, EasyPeasy is my first choice. The API isn’t too different.

What I did to always get a new access token when calling an API endpoint was to use thunks. Before I call my thunk from a component, I invoke the getAccessTokenSilently method and then pass the token as a payload for the thunk (async action) along with any other data it needs. As such, the Redux/EasyPeasy/anyLibrary doesn’t need to have direct access to the SDK to call the getAccessTokenSilently method.

Other than that, if you need larger or direct access to Auth0-related methods outside of the React component layer, the best alternative seems to use the Auth0 SPA SDK as currently, there is no way to initialize and access the Auth0 Client outside of the React component layer when using the Auth0 React SDK.

2 Likes

Hey @dan-auth0, any plans to expose getAccessTokenSilently outside of React components (using auth0-react) in the future? The library does abstract away quite a bit of the auth0-spa-js implementation details so it would be nice if it could support more use cases.

As others have said, passing the token from inside a component isn’t ideal and leads to a lot of unnecessary duplication.

I was struggling with the same problem and ran into this gist (my code is further down the comments):

Would prefer a cleaner solution but it seems to work fine.

2 Likes

Thanks for sharing it with the rest of community!

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