If i host my Identityserver4 and the Api in the same Asp.net Application.
What will be used for authentication for the API Controllers?
The Cookie from Identityserver or the token which i get from the oidc-client in my SPA application?
I my tests i can access the API, also if i didn't send the token within the angular http reqeuest as long as i have the Cookie...
But is this a correct and save way???
The MVC Controllers for Identityserver are protected with ValidateAntiforgeryKey, but not the API Controllers.
Does it make sense to host both in the same Application???
Edit:
In Details, the API is used for managing the IdentityServer.
CRUD Operations for Clients, Users, Resources,...
For example:
The IdentityServer is reachable at http://localhost:5000
I want build an Angular2 SPA Admin UI which is available at http://localhost:5000/admin
The reason for mentioning ValidateAntiforgeryKey is, because if i only use Cookie Authentication for the CRUD API i should also protect these API'S with ValidateAntiforgerKey, or?
It sounds like your API and Identity Server are two separate concerns and should be handled as two separate apps. This makes it a lot easier to maintain.
You need to set up an ApiResource and a Client where you add the ApiResource as an AllowedScope in your Identity Server configuration.
Then in your API app, you must add add the authentication middleware UseIdentityServerAuthentication.
The details are explained here:
http://docs.identityserver.io/en/latest/topics/apis.html
I can see you are mentioning ValidateAntiforgeryKey. This attribute is not used for protecting against unauthorized users, but to make sure form data is being posted from legitimate forms.
Related
In one of my project need to consume JWT token from asp.net core web application. My trial project is on github https://github.com/SapanPatibandha/JWTAuthentication
This has one server JWTAuthentication which is generating jwt token base on username and password.
Second component is AnyAPI which method is protected by self verification of JWT.
Third important part and where I have problem is Web application.
Need to create login screen in this application, base on this user detail call login api from JWTAuthentication and use that token for all further use of api from that web application.
I am not sure about middleware configuration and how to store this token on web application.
Thanks
IMO, What you asking for is a journey that need some investigating time, that's not what could be answered shortly, so... I'm gonna make this as compact as possible
What you're doing in the repo is hand-generate and validate Jwt Token. If that's required, investigate these stuff:
Generating Jwt on central identity provider server (which you currently have)
Validate Jwt on api resource (which you currently comment that out)
On application(seems like you make use of classic MVC or razor page), create login form that use ajax to get Jwt from identity provider server, store it on client side (browser), then attach it with every request that make use of AnyAPI, by cookie or header or something you saw reasonable. Or if you choose to save the token on Server side, implement your own session-Jwt mapping logic(Actually, some kind of Js SPA would be more suitable for this kind of approach).
Another approach would be implement a more proper Oauth implementation. I consider 2 most widely acknowledged in .net ecosystem would be Identity Server and OpenIdDict. Highly recommend to check them out.
Vue front-end for SPA and asp.net core 3.1 as backend for API
Using Microsoft.AspNetCore.SpaServices.Extensions nuget package so, among others, SPA files will be served from a folder (wwwroot/dist) when users access .net core
Back end API controller is decorated with [Authorize] attribute
SPA router has authguards so protected routes are only available to authenticated users
SPA will use Axios and pass a bearer token to the back end API
I want to implement OAuth2/Oidc authorization code with pkce using the identityserver4 hosted on another system.
A request for the landing page should forward the user to identityserver4 for the login/password prompt and redirect back after completing all the steps with a token.
Ideally I want the .net core handle all the oauth/oidc steps and don't want to deal with it using oidc-client javascript client in SPA. Any suggestion on how I can accomplish this? Thanks
Well there are two standard models here and you need to choose one of them, depending on factors you care most about:
OPTION 1: SPA SCENARIO
The SPA is the OAuth client and authenticates via Javascript tech
The API is the OAuth resource server
It is not standard for a resource server to handle the authentication flow for a client - instead a client should authenticate, then call the resource server.
OPTION 2: WEB BACK END SCENARIO
People most commonly choose this option when they want to keep tokens out of the browser's Javascript code:
A Web Back End in C# is the OAuth client
The Web Back End needs to securely communicate with the browser and has to use an auth cookie for this
To call an API the browser needs to either send the cookie to the web back end to get a token, or double hop all API calls via the web back end
ABOUT OIDC CLIENT
Personally I prefer option 1, which I think is closer to overall SPA Goals, such as cross domain hosting and use of content delivery networks. OIDC Client can actually lead to a fairly simple SPA security implementation, as in this
Client Side Implementation of mine.
I am developing ASP NET Core Web API and I am confused by choosing the authentication method. I used to apply default Asp Net Identity authentication, but recently I've known about JWT. So I've implemented Authentication almost as it done in this article: https://stormpath.com/blog/token-authentication-asp-net-core.
But I can't understand the benefits of this JWT. With simple Asp Net Identity Authentication, I don't care about token storage etc. I only need to log in with signInManager and use authorized methods until logout. With JWT I need to think about the token store, expiration, and other difficulties. So, what're the benefits of this JWT? How can I store this JWT token after login? Furthermore, should I even use this JWT? In my case, I need simple authentication for simple WebApi which will be used by one or little bit more users. I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
This is the way I understand this, split in to 3 logical parts.
Authentication Server - this will authenticate and issue the JWT token, when the API need's to validate the token it will send the token to this server to validate it.
Client - this is what serves your web pages, or you app perhaps. This is what will need to request and store the the JWT token. The client will need to pass the token to the api every time it requests data.
API - this is what serves the information and needs to validate the token with the Authentication Server.
So, what're the benefits of this JWT?
JWT is issued to the client and stored on the client side. Having JWT allows multiple client's (App's or Websites) use the same authentication server which distributes JWT and states which API's the client's can use and how.
How can I store this JWT token after login?
I only tried to store it in an Ionic 2 app which uses angular 2 which has a storage module. But i'm pretty sure numerous people have done this already and asked this question:
Simple JWT authentication in ASP.NET Core 1.0 Web API
Token Based Authentication in ASP.NET Core (refreshed)
Update
If your front end is made purely html/js/css and doesn't have a back end to accommodate it you would store your token in local storage, there a multiple npm packages that help you with this like this one. You want to look for Implicit flow.
Otherwise if you do have a back end that comes with your front end you want to store the token in a session/database your pick, there are 3rd party providers to do this like IdentityServer4. You want to use Hybrid flow
Furthermore, should I even use this JWT? In my case, I need simple
authentication for simple WebApi which will be used by one or little
bit more users.
The reason for the whole separation of concerns is performance so you don't really need it since it's just one or a little more users. Do it because it's a learning experience, JWT is not easy to setup from the beginning and will require you to do a lot of reading and you will fail and you will be frustrated but at the end you will know how to set it up and how it works
I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
So what you did in the Stormpath tutorial is NOT production ready. That is just a little demo, to help you understand what JWT is and how it works. The above mentioned are complete libraries that tackle all the heavy lifting and do not require you to built the whole thing from scratch. And the main difference between them is the scope that they cover.
I personally used IS4 and it had me crying no more than 2 times (It was simpler than I thought):
http://identityserver4.readthedocs.io/en/release/
https://github.com/openiddict/openiddict-core
https://auth0.com/docs/quickstart/webapp/aspnet-core/00-intro
Use tokens (JWT) if you have multiple applications or services (web, mobile, other services) connection to your API. Benefits: Stateless, Scalability, No cookie, no CORS problems (if you allow it).
If your API will be used by only one web application use the default ASP default authentication system. Its easier to set up.
If you webapi and user interface are hosted in the same web application, token bases security does not buy you anything over the cookie based authentication provided by the built in authentication. That's because the authentication cookie gets sent back to the keep application on every HTTP request. When you make calls to a website other than the one you signed in on those cookies do not get sent. So JSON Web Tokens (JWT) provide a standard format for browser to send identity information to a website when a cookie isn't an option.
If your Web Api is to be accessed by AJAX calls then JWT may be a desired choice, but not mandatory. judging by the description of your app,it seems to me that the default authentication system can serve you well.
Auth2 is the authentication mechanism that enable external login such as Facebook. It is part of the default authentication system, and you need not do much in order to employ it in your app.
OpenIddict sits on top of Auth2. It is part of the default authentication system, and you need not do much in order to employ it in your app. It is the authentication mechanism that enable external login such as Google+
IdentityServer may be used for large Wep Api that is accessed by Ajax calls. As for instance, you can use IdentityServer to authenticate users longing to a front end Angular app.
Once again, the default authentication system can serve you well.
Hope this helps...
I am currently working on a solution that includes a multi tenant webApi which will be accessed by multiple clients, some of which i will be creating, some of which others will be creating.
Access to the api will be available via an ApiKey & Secret (enough for some resources) as well as username & password (for owner resources).
At the moment, the clients i have created (.Net MVC Web apps) have their own membership systems so what happens is the user of the client logs into the client system and the client system passes the login information to the Api to retrieve an authentication token.
The client membership system is really an unneeded abstraction. What i really want to do is have the user log directly into the api and the api pass back an authentication token that can be used from the browser as well as the .Net MVC client app.
My question is, what it the best way to achieve this. In my mind i seem to be struggling with 2 solutions.
1) Have a browser based login (ajax/AngularJS for instance) solution that calls the api to retrieve a token which then passes that token onto the MVC client where it will be stored (session variable maybe). Any future calls to the api that come from the .Net MVC client can pass the token on. This seems wrong to me though. I'm not even sure this is possible.
2) Utilise one of the OAuth flows so that the browser based login can call the API and retrieve a token, and the OAuth flow redirects to the MVC client which then stores the token for that user (again, in a session variable).
The Api was generated using the VS2013 WebApi template using Owin local accounts and is generating tokens via the ValidateClientCredentials and ValidateResourceOwnerCredentials flows, but i think i need to use one of the other OAuth flows for this scenario.
I understand that another solution would be to bypass the .Net MVC client code and create a completely browser based solution using knockout or AngluarJS but it's quite a complex system and i don't really have time to do this at the moment so i'm looking for a solution that would allow me to retrieve a token from the api that can be used from my .Net MVC client and ajax calls from the browser.
Any ideas, advice would be much appreciated.
thanks in advance. Justin
If you'd rely on Azure AD as your credentials store and authentication system, you'd be able to leverage a ready to use JS library that handles authentication, AJAX calls and session management concerns automatically: see http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/.
If you can't rely on Azure AD, the code of the library and samples mentioned above can still have value as a reference to build your own system - provided that the authenticaiton system you decide to use offers similar capabilities.
HTH
V.
I'm quite new to asp.net mvc webapi technologies.
Scenario:
I'm desiging a mvc web application for enterprise. I'm aware that MVC controllers can have authorization and authentication via security attributes.
The web application shows various trends for household water consumption. The vision is to have this data accessible via mobile, tablets (you name it).
I'm wondering whehter WebAPI would be better off then controllers so that same API can be consumed by many devices.
Question:
The question I've with webapi is the security. On web application once user logged in controller knows the user's security profile etc. In case of devices how would the security work? Should all the clients must pass credentials and if it is how is secruity handled on server? Should we create one service account and provide to each clients?
Thank you, not sure if I explained well.
MVC Security is an overlay of standard ASP.Net Authentication/Authorization. The AuthorizeAttribute indicates that the user must be authenticated to access this resource. It looks at the User IPrincipal for IsAuthenticated and Roles
So this then becomes an ASP.NET authentication solution.
User Authentication - Straightforward using any of the mentioned methods in the first article.
Device Authentication - No generic answer for this and there really isn't a true secure way of authenticating a device. You can identify the device by passing unique data (device Serial) in the URL or HTTP Header.