I'm building my authentication manually using Auth0 API's since there is no SDK for SvelteKit at the time I'm writing this question.
So far I managed to get an Access Token, send it in a cookie to the browser and send it back at every request for a check using the Auth0 API for user profiles before passing the request to an endpoint.
The problem is the lack of speed. It takes about 1s to navigate from one page to another in the browser.
I don't think I can keep Access Tokens in memory server-side (due to the nature of SvelteKit) but I want to keep things simple.
Is there an alternative to Auth0 with a faster API?
Related
I am building a website using .net. The plan is to use the strava api to get activity data of the user.
Currently the user will need to accept this strava prompt every time he reloads my site:
I got the auth flow working but my question is how to keep the user logged in. If I only store the tokens on my server I won't recognize the user on reload (or I have to use separate authentication). However if I store the tokens on the client the user will be able to make requests to the strava api on behalf on my application.
I tried to add custom jwt authentication to my server but don't like the complexity this is adding. I want to avoid it if possible.
Which of these is the standard way of doing it? Or is there a different strategy I am not seeing?
I'm trying to implement Google authentication for my app and the below is the workflow I'm trying to set up.
First, user will authenticate with Google and obtain an access token.
User will make requests with this token to backend services.
Backend services will check with Google to validate these token
Once validated, backend services will send information requested by client back to users
And I have a couple question around it:
Is this the correct way to implement it?
How to avoid check with Google for every single request between Backend and Frontend?
It's sort of the correct way. It depends on the details. If I understand correctly, you are in control of the front and backend (these are both your applications). If this is the case, then you would rather use Google services only to authenticate the user (so use an OpenID Connect flow to get an ID token to verify the user's identity). After that, you would have your backend either issue an access token or establish a session with your frontend. Then you wouldn't have to ask Google for the token's validity every time someone makes a request to your backend.
An access token that you get from Google, Facebook, etc. is meant to be used with their APIs. You could use it to authorize access to your own backend, but you then have to call Google on every request to verify the token. You are also tightly coupled to Google's details of the access token usage — what scopes are available, what data is returned with the token, expiration times, etc.
If the access token is a JWT, then you can verify it on your own in your backend. You don't have to call the issuer every time. But, if I remember correctly, Google issues opaque tokens, so this is not the way to go here.
To sum up. If you're in control of the front and back end, then authenticate with Google, then start a session between your applications. This will be simpler to maintain and also safer, as you wouldn't have to handle tokens in the browser.
We are trying to implement Auth0 in our next+fastify based application. The login page is custom and we want to integrate the login using the embedded login from the fastify server.
I am naive to oAuth and Auth0, I have a few doubts around it:
How do we verify the token? Do we verify the JWT and maintain the token on or fastify server or should we always the validate the token on Auth0 endpoint? I tried calling the userinfo endpoint which resulted in rate limiting. So, I interpret if we just verify the JWT on server instead of sending to Auth0 server. Also we send and maintain the JWT in cookies to validate the client always. Is the understading correct?
Is embedded login safe enough to be used in production? Are there any risk associated around it?
Is the approach correct? Is there any alternative way to implement the login flow? We also need to integrate reset password and rest of the functionality. I have read the SDK docs and it seems to have support for all.
Thanks a lot in advance
There are several options to validate a token issued by auth0, they recommend you to take advantage of middleware to verify the token. Multiple frameworks have their own middleware to check and validate JWT. It's as easy as integrate middleware with your application and perform validation when you need it. Check this:
https://auth0.com/docs/tokens/json-web-tokens/validate-json-web-tokens
In my opinion, it is always better to go with the Universal Login option of auth0, since embedded login sometimes incur into the cross origin authentication issue. Remember, when a user tries to log into your application using auth0, it redirects the user to another domain that differs from the one serving your application. In my experience, using the universal login provides you more information about the login process of your users, and that makes the process of debugging errors and auth processes easier. You can read more about login with auth0 here:
https://auth0.com/docs/login/embedded-login
https://auth0.com/docs/login/embedded-login/cross-origin-authentication
Yep, you can integrate the reset password process, which is almost entirely handled by auth0 itself. As I said earlier, we use Universal Login for our applications since it provides more control over the authentication flow. That doesn't mean you can't use Embedded login, it is a very good option too, but it seems more focused in UX rather than control auth flow.
Check this link if you still have doubts about the best approach: https://auth0.com/docs/universal-login/universal-vs-embedded-login
I have a question more related to the way OAuth 2 is working but since using IdentityServer to implement OAuth I think it's relevant. I could not find an answer anywhere.
I'm building a website and a mobile app that consumes my own API. Each user of my app will have a username and password, that will give him access to the app/website and though the API to his information.
I'm not sure about the right way to handle the flow for user login:
On the website I have my own designed login form. I don't want to move the user to my auth server to login, and then have him approve the information he gives - he is the user on my system - I have access to all information - kida like facebook has a login and access to the informatio - they don't ask what you're willing to give them. So is implicit really the way for this?
On the mobile app I also have a login form and now I read here (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10) that the OAuth approach is to have the login in a WebView?? Doesn't look like facebook login is in a WebView on their mobile app.
The approach I was first lookin at is the Resource Owner. Users will login, get the token and the refresh token and can start working against my APIs. But storing my client_id and secret on the mobile app? on the website javascript files? doesn't feel right. I can of course make a call to an API that will mask those and be a proxy to the login process... but... (read #4).
In the future I would like to allow access for third-party developers. For them to allow login for users of my system I will use the implicit flow. Also, I plan for those developer accounts to have restricted API access (for example, the number of calls to the API will be limited by plan). What prevents those developers from asking for the username and password of their account on my system on their website, getting the response from my servers with the access token and refresh token, and using my API however they want, without restrictions, and having access to the entire user profile?
Lets say I'm sticking to the resource owner flow, receiving back from the server a token and a refresh token. What should I store on the mobile device and how? What should be stored in the browser and how? the refresh token? and each time he opens the app get a new updated token with that refresh token?
Edit
Just to clarify, because I find a lot of lectures and articles that explain the process from an API consumer point of view (ie. the third-party developer): I am the API owner and the auth server owner, I'm the owner of the user accounts (they are my users of my services), I'm also my own consumer (though the website and the mobile app), and in the future I want to enable third-party developers to allow my users to login with their accounts of my service (kinda like Facebook or Google)
You're correct that you shouldn't store the client_secret in your app, but I doubt you will get around storing the client_id. You could disable the consent screen for your app as well, and build a native login view. You need to store the access_token and the refresh_token on the device (maybe encrypted in a database) if you don't want the user to login everytime they use your app.
As for problem 4, you could do the following:
Embed the client_secret in your (web) app
Set up which hosts have access to your api on the IdentityServer
The IdentityServer generates a salt and sends it to the client
The client calculates a session_secret using hash(ip_address + session_salt)
The client uses the session_secret and the client_secret for the API call
Server validates the hash and client_secret
It's nearly impossible to completely prevent someone from using your API. But you should add various rate limiting methods, such as limiting IP addresses, API calls etc. But nothing will stop someone decompiling your app and accessing your client_id.
I've an ETL tool that is capable of making REST API calls against the Yammer network and retrieving data for analysis. Currently, how I make Yammer REST API calls is through an App that I've created. I then generated the authentication token and then used this token in the REST API calls to get at the data.
What I'd really like to do now is to provide an app that allows me to call the REST API (using the same ETL tool) without the person installing the app to have to go through the rigmarole of generating the auth token.
I suppose one approach could be to use some JavaScript that displayed the token to the user so that they could then pass it on to us... Do you folks have any other suggestions as to how I might do this?
There isn't a recommended way to skip the OAuth authorization, but you can automate a lot of it away. I created a Python script that uses the YamPy library to acquire a token. It even fires up the browser to the correct URL for authorization. You should be able to do something similar with other languages.
Calling the impersonation endpoint is another possibility. This will get you an OAuth token for another user so you'd need to have an app is just for producing OAuth tokens. It's probably a bit trickier to build right and secure than my script. Impersonation was designed for a specific category of app which means I don't recommend it by default. Even when it is a workable option it hides the authorization from end users which can potentially be a security issue, if say you app is compromised and handing out OAuth tokens. At least if the Yammer screen is in the way it's a bit more visible to the user what is happening.