Currently I have a working IdentityServer4 service that allows users to authenticate to active directory only. They authenticate and then they have no issue accessing the api. I'm using the the IDP server from IdentityServer4 Quickstart with all the local user account stuff stripped out. Here is my database:
My question is this, were are tokens stored? Only in the browser? Am I doing something wrong? Should there be some sort of database that holds tokens for SSO? It is working but I'm worried I'm missing out on some sort of functionality.
The PersistedGrants table stores the following type of tokens: authorization_code, refresh_token, reference_token, and user_consent.
Regular id_tokens and access_tokens are not persisted in the database, they will be passed to the client to be handled as it sees fit.
SSO is achieved when your IDP server creates a cookie contain identity and session information for your browser to reuse.
Related
We are trying to build an application which is going to use WSO2 identity server to authenticate with IDP initiated SSO .
I have tried out the travelocity.com example in the WSO2IS tutorials , and I can understand that the "default" authentication type as Local Outbound Authentication uses the Primary user store to perform authentication :
What I need to understand is , how do I map a UserStore to work with a particular service provider , I am performing SSO as IDP initiated ?
Is it something I can manage inside the WSO2 Management Console ? OR do I have to modify the authenticationendpoint webapp?
It isn't limited to the PRIMARY user store and if you have multiple secondary user stores, it'll try to authenticate the user with every user store until the authentication is success.
Limiting a user store to a certain service provider is currently not available in the Identity Server but you can write a custom authenticator and achieve this requirement. Here is a guide on how to write a custom local authenticator. Basically what you have to do is, overide the processAuthenticationResponse method and pick the user store accordingly.
Based on you described requirement, I would like to suggest another approach to achieve the same.
In WSO2 Identity Server you have the capability engage a policy in the authentication flow. So using a policy we can restrict which user stores are allowed for a particular service provider.
Check out https://medium.com/#Pushpalanka/application-wise-authorization-wso2-identity-server-user-store-per-service-provider-dfea5f9ad758 for a detailed explaination.
I'm creating my first SPA using NodeJS stack for development and I came to a point where I should design authentication and secure some parts of the app.
I read a lot about auth techniques including JWT, OAuth, etc. but I still didn't find something like «a real world example».
Let's assume that my task is just to secure some parts of app from public. My app isn't designed to work with 3rd party services so I see no need to use something like Google or Facebook auth. I want to use login/password and store all this data using my own database server.
I don't understand the point of having authentication stateless. I came to a simple conclusion that I can design authentication in this way:
I store users logins and passwords in my database.
User auth means that user enters his credentials, server checks it and creates token. Then server saves this token into database. User saves token using browser local storage or somewhere else if it's not browser environment.
On each request client sends this token, server checks that this token exists and responds appropriately.
User can login from different devices, we just create multiple tokens for him.
We can end specific session or all sessions by just deleting user tokens from database.
We can manage tokens in a way we want, for example server can check expiration time and invalidate (delete) token.
Is it OK? JWT require additional implementation if we need to invalidate token, I saw different examples, all of them were based on storing invalid tokens but what's the point of that if we can just store valid tokens? We already lose statelessness by implementing this storage.
I see that I can just use cookies instead of implementation described above but I don't like an idea to use cookies in RESTful app because it really depends on browser-like client environment.
What are the disadvantages of just storing tokens on server?
I have implemented one project in which user authentication is required and token is stored into database.
You can find that example here.
You are describing the traditional authentication approach using session cookies. The server stores a session for each connected user identified by a sessionid. The sessionid is stored by client in a cookie and sent in each following request to identify user.
You can use this method perfectly, both in browsers or mobile devices (using the device storage instead of a cookie)
The drawback is that it requires many server resources to keep sessions open and requires database queries at each authentication to retrieve user data. This is what JWT solves. The user information goes in the token itself, and is reliable because it is signed with the secret key of the server.
JWT has its own drawbacks, for example it is not useful if you need to have a revocation list, because them will require server storage.
I'm working on setting up a new SSO application. I would like to use ASP.NET Identity as a database to store the users data. I have a ReactJs application hosted on Node.JS and a .Net Web Api2 application. I want to protect thsi Web Api 2 using Identity Server with users from its database. In further development I'm going to create a mobile application.
I'm able to create an asp.net identity database with some users and use Resource Owner credentials, but I have couple of questions if anyone could help:
Why is Resource Owner Credentials not recommended? My current workflow is to hit the api with client&user&password and obtain a token which I store in web layer and use in Web Api requests. Web Api validates the tokens and identify the user. I read on IS page that's not recommended then what's the recommended scenario to authenticate the user?
How can I create an authenticator for mobile? Should I create my own certificate issue, store it in database as a thumbprint and use access token for that?
Thanks
In short, Resource Owner requires the credentials to be passed through the application itself, also RO doesn't give you SSO. Here's a longer answer. The recommended scenario is to use hybrid flow with PKCE enabled.
Look up TOTP. I believe it is implemented in AspNetCore.Identity with some examples.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.