Can I get an idToken from an auth0 rule? - auth0

Is there a way that I can get access to the idtoken that would have been generated on a user creation in the auth0 rules context?
I'd like to sync user registrations to my backend system and need the idtoken that the auth0 signup would have generated. That way I can http post that data in my rules trigger.

No, because the ID token is only generated when all rules finish executing. The reason for this is that further rules might deny the user from authenticating or modify their profile before the actual token gets generated.
The proper way to do this would be to define your backend as a resource server on Auth0, and use Client Credentials from the rule: https://auth0.com/docs/api-auth/grant/client-credentials.
Another alternative is to call the Auth0 Management API to fetch user information from your backend when necessary.

Related

User Authorization with in MERN

I am trying to create user roles like admin and users for my MERN project. But, I didn't get any good documentation or resources for it. So, please anyone who know good documentation or resources, suggest me or provide me a good sample of user authorization with MERN stack
You might find it helpful. It explains authentication and authorization in MERN stack on the basis or user roles.
https://abbasimusab2000.medium.com/authentication-with-react-and-node-de7384199a29
Although if you prefer to read official documentation here are few elements that will be useful for both authentication and authorization.
Backend
Let's consider you are creating/registering a user you can use bcryptjs for password hashing for security. Once the user is registered you can use bcryptjs function called comparesync to match hash and plain password, next you can create a token using jsonwebtoken and send it to frontend.
Frontend
Now on login if the user has entered correct credentials, then the backend will send a token, you can save it in local storage of cookie. For cookies you can use js-cookie.
Now if you need to add authorization you can send token with request on backend and then the backend will use a middleware for authentication by decoding the jwt and then will execute further logic.

Need to configure Spartacus3 with Auth0

I have to use Auth0 for the application and need to bypass Spartacus password login flow. I have gone through https://sap.github.io/spartacus-docs/session-management/#configuring-authorization-code-flow-or implicit-flow found that there is implicit flow to bypass login.
Tried with "authorizationserver/oauth/token" API hit manually and store token in local storage but getting other issues.
Can I know better approach to implement Auth0 in Spartacus and bypass password login flow.
Spartacus supports 3 flows with OAuth without any serious modifications required.
Password flow -> the default one. You login in spartacus form and the credentials are send to server and exchanged for access_token.
Implicit flow -> When you click login you are redirected to OAuth server login page. You put credentials there and after that you get redirected back to spartacus with access_token in on of the query params of the redirect url.
Authorization Code flow -> similar to Implicit flow, but in response you get code which then you need to send to oAuth server to exchange it for access_token.
To specify which flow you want to use you need to change the responseType config as mentioned in https://sap.github.io/spartacus-docs/session-management/#configuring-authorization-code-flow-or-implicit-flow
For Auth0 I would recommend going with Authorization Code Flow (as it's more secure than Implicit flow, especially with PKCE enabled).
Apart from the responseType you would need to set baseUrl in auth config to point it to Auth0 server (and I assume you have integration done in the backend that can verify tokens returned from Auth0). You might need to adjust few other config options as well, but you should be able to figure those out based on the problems you encounter.

Getting refresh_token server-side (sessionToken) with Okta

We wish to use our own httponly strict cookie with access and refresh token in it for our microservices architectures.
We are primary using OKTA Authentication API to log users with our own custom Sign-in page.
We were able to get the access_token on the authorize endpoint using the responsetype=token with sessionToken and redirecting the result as a form_post on our back-end endpoint.
I was unable to retrieve the refresh_token despite adding the offline_access in the scope even if it is checked in my okta application setting.
I don’t want to use resource password flow since we prefer using sessionToken which will work with multi factor if needed in the future.
I also try using the code flow and redirecting the result on our back-end but since the code flow is client-side it’s return this error "PKCE code verifier is required when the token endpoint authentication method is ‘NONE’." This error occur even if we choose a .NET application
How can we retrieve the refresh_token server-side with Okta?
Responded to your post here https://devforum.okta.com/t/getting-refresh-token-server-side-sessiontoken/12419/3.
Aside from making a call directly to /token with your access token you can also check our Early Access feature called Refresh Token Rotation. Let us know if this helps!
I was able to use the CODE flow and redirect from server-side to the authorized endpoint like so:
https://{YOUROKTADOMAIN}/oauth2/default/v1/authorize?client_id={YOURCLIENTID}&response_type=code&scope=openid%20offline_access&response_mode=query&redirect_uri={YOURSERVERSIDEGETURI}&state={Guid.NewGuid()}&sessionToken={SessionToken From Auth API}
This call will post back to my same server, so i can handle token myself and create my own cookie.

Why shouldn't I use IdToken as bearer token in an IDP context?

I am using an IDP platform (here AWS Cognito but that could be Auth0, OKTA or Keycloak) and I was wondering why I was discouraged to use the ID Token as an authorization token.
To be more specific, I will not make use of a resource server with authorization delegation from a user to a third-party app. My IDP will just let me SSO all my users on my different applications. There is no scope to grant here, only authentication claims that each service will use to grant or refuse access to resources (like an email, user ID, or the roles).
I understand I could provide my application with the id token and then create some session for my user. By why shouldn't I use the id token itself as a stateless session token, given that its signature can be checked on each application's back-end ?
And if I should use an access token over the id token - can I replace scopes by roles ? Or how should I understand the scopes in a non-delegation context ("user is usign the app himself, not giving permission" vs "user is giving all scopes to the SPA front-end which is an application in itself")
By the way, I am recovering the tokens through code PKCE flow on the front end.
The ID token only contains details about the user and how the user authenicated. so its perfect for creating a longer lasting cookie session with the user. The default lifetime for and ID-token is very short as well, like minutes. You typically throw the id-token away after establishing the sesson. You should never ever pass the ID-token around to other services.
The access token is mean to give you access to the APIs that the token is intended for.
when the user signs in, you ask for acceess to certain scopes and the scopes selected (consented) by the user , then is included in the access token (as scopes and audience claims).
In theory you can pass the ID-token to an API, bits not how its supposed to work.
See this and this for more details:

oAuth 2.0 - Acting on behalf of the user

I'm new to oAUth2 and I'm trying to get a few things straight.
I understand the basic principles involved with oAuth2 but I am not sure how to implement it in my situation.
I am writing an app that acts on behalf of the user to automate a manual process and perform some tasks(update/request status...etc). The API we are connecting to uses oAuth2 to grant our application permission. We plan on having the user grant our application permission when they create a new account with us.
I understand that the user will request an authentication code that is provided to our application. Then our application will use the authentication code to generate an access token.
We would like to do this only once. Then act as the user to send and receive notifications without having to have the user to log into the service with their credentials.
I am not sure how to implement this without having to store the user credentials to get an auth code since the auth code and auth tokens expire. I'm guessing that this is a common scenario.
What would I need to do to get what I want accomplished?
You can get a new AccessToken using a RefreshToken, if this is provided by the Authorization Server.
If it's not provided I would contact the Api provider, you should never store a users credentials. In fact if the OAuth protocol is well implemented as a client you should never be able to even get the client credentials. When the user has to login you should redirect the user to the Authorization Server, there the user should login and then the authorization token should be redirected to your application by the Authorization Server.
See also this explanation on Refresh Tokens from the OAuth 2.0 spec:
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token
Note
If you request a new AccessToken using your RefreshToken and the response includes a new RefreshToken you should overwrite your currently saved RefreshToken. With other words, you should always use the latest RefresthToken you received.