I've stood up an instance of identityserver4, an API project, and a UI.
The workflow is as follows:
User visits the UI.
User provides user name and password to UI.
UI sends credentials to back of web app, which uses a password grant to authenticate the user with IdentityServer4.
IdentityServer4 returns a token.
Token is used to identify who the user is to the UI and that the user has access to certain sections of the site.
When the user needs to do something within the site, the token is passed to the API via bearer auth.
The password grant isn't negotiable, as this is a first party app and it makes no sense to redirect the user away from the main site.
What's the proper set of middleware to use for this? Should I just use a CookieAuthenticationMiddleware and attach the token as a claim? I'll need to access the claims from HttpContext.User claims. Do I need to use IdentityMiddleware?
You can request identity scopes using the password grant type and use the userinfo endpoint to resolve them to claims - like in this sample:
https://github.com/IdentityServer/IdentityServer4.Samples/tree/dev/Clients/src/ConsoleResourceOwnerFlowUserInfo
And yes - you can use the cookie middleware to persist those claims and the access token for later usage.
Related
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:
I have a Node.js lambda API that's called by an authenticated user. The user is able to access the API passing a valid JWT token. Now I'd like to interact with Cognito User Pool to change the user's email, password and etc but I haven't figured out how to achieve this using just the JWT.
I've made several tests using amplify-js and amazon-cognito-identity-js
You can reset the user's password by calling an admin API call, not through the JWT token. https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html This will prompt the user for a new password.
This API call is to set a password for that particular user https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html but I prefer the first option.
In order to change user attributes (such as email, birthday...), use https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html
So all these are done using the Cognito Service inside the Lambda (not to be confused with the JWT tokens).
I have followed a few guides on adding authentication to my vue application (which has a net core api backend).
https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
and
http://jasonwatmore.com/post/2018/08/14/aspnet-core-21-jwt-authentication-tutorial-with-example-api
I'm a junior programmer with authentication so forgive me if my questions seem dumb.
These involve sending a username and password to my api login method and getting back a jwt token (is this an id_token or an access token?). I then send this token with every api request using the Bearer authorization. Some guides (eg microsoft net core docs) have this jwt token include role information.
Is this just a basic form of jwt authentication. Some things i have read about token authentication indicate that when i login i should get an id token which i then exchange for an api access token. These tutorials don't appear to do that - it looks like there is only one token and that it's used for api access and authentication.
Ideally i would like to implement oidc into my vue application but the many guides out there dont seem to address this.
The tutorials are talking about the JWT token based authentication , it will issue a JWT token to declare a user and their access permissions in the application.
When a user tries to log in to the application with their username and password, the server/api side will authenticate the user ,generate the token and send token back to client . Next time client could use token to access the server/API which eliminates the need for the app or system to remember or store the user’s credentials. You can involve user's basic profile information(not sensitive) and some custom claim in that token such as claim related to roles . Both client side and server side should check the specific role if you want to check the authorize part .
Id_token was added to the OIDC specification(OpenID Connect) as an optimization so the application can know the identity of the user, without having to make an additional network requests. It contains user profile information (like the user's name, email, and so forth) , and So if you are using OpenID Connect (Implicit Flow is suitable for SPA) to do the authentication and authorization , you will get id token which identity of the user , and access token which could be used to access the protected resource/API .
You are not using OpenID Connect , so no id token is involved in the scenario .
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.
Is there a way to pass login credentials from code instead of entering credentials everytime in the popup for login authorization?
You dont require login credentials every time for authorization,you'll get an access token and access secret upon successfull authorization by OAuth,use the later for further calls to the API.Oauth protocol works this way.
I guess Magento is using OAuth 1.0/1.0a,so everytime you'll authorize a user you get,
oauth_token - the Access Token that provides access to protected resources.
oauth_token_secret - the secret that is associated with the Access Token.
You will need to use OAUTH based authentication. Then pass the request token along with each request:
Refer: http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html