I write a webapp with mvc5 and Identity for authentication. It's work fine.
Now I need to authenticate same client (ios app, windows phone app, and android app) with users that are registered. Think to use a specific webapi where user can register, modify, autheticate ours user. So when they are autenticated the use can access other webapi for get data. Is this correct procedure? How I can use Identity into webapi?
Thanks
You want to look into oAuth and JWT tokens. There is already a library built for this which works really well called Thinktecure. When you are authenticating from a mobile app you really want to go the route of stateless authentication and just pass a token with the necessary claims to identify the user. There is plenty of documentation on the site as well as a sample repo (below).
https://github.com/IdentityServer/IdentityServer3.Samples/
Related
Hello all and thanks first,
I have a project that has .NET Core 2 API and Angular 8 Client application. I have implemented token based authentication between app and the api (without using IdentityUser or IdentityRole).
Now, I have to do authentication over SSO. I have a saml2 identity provider metadata and configured my api using this metadata using Sustainsys.Saml2.AspNetCore2 package.
Now I can create my own metadata and registered this metadata to IdentityProvider. Everything seems okay
up to this point but when I try to login from IdentityProvider login page there is no change on my api.
Crazy questions in my mind
In Identity Provider's metadata there are only SSO and SLO redirect urls. There is no other method for authnrequests.(HTTP POST etc.) How will I login this Idp?
Idp has its own login page. If I will be have to redirect user to this login page, will I get any authentication token or cookie. Will my API be recognized about this login?
There should be an authentication data in any case(token, cooke, sessionid etc.). Where will I get this data to set Authorization header while sending requests to my API?
I have been trying for a while but my last attempt also does not work.
Can anybody help please?
Thanks a lot.
You need to redirect to the identity provider, and it will then redirect back to your service provider api, from which you can set whatever security mechanisms you are using, and then redirect again to your local front-end (wherever you need to send your user).
Here are some resources I found helpful:
1) https://learn.microsoft.com/en-us/aspnet/core/security/authentication/?view=aspnetcore-3.1 (how authentication schemes work in .Net Core)
2) ASP.Net Core SAML authentication
1. https://github.com/Sustainsys/Saml2 (SAML 2.0 authentication package)
2. https://stubidp.sustainsys.com/ (Free IdP – can be used instead of local implementation, if desired. A local implementation would require deployment of the “Sustainsys.Saml2.StubIdp” project).
3) Sustainsys SAML2 Sample for ASP.NET Core WebAPI without Identity
4) https://github.com/hmacat/Saml2WebAPIAndAngularSpaExample (super useful sample implementation)
5) Not able to SignOut using Saml2 from Sustainsys (help in getting the logout to work with https://stubidp.sustainsys.com)
6) https://www.nuget.org/packages/Sustainsys.Saml2.AspNetCore2/
I am building a SPA using React and Redux on top of dotnet core 2.0. Unfortunately, the vs2017 template for this does not include Authentication/Authorization.
In looking around, I saw many people talking about the use of JWT's and suggesting things like Identity Server or OpenIddict to handle this, but I have only ever used ASP.NET identity to handle security before.
My question is, is it possible to secure a react app by using ASP.NET identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
I will try to answer by your questions.
Q.1. Is it possible to secure a react app by using aspnet identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Q.2. Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
Answer To First Question(this question technically related to difference between cookie based and token based authentication approach.)
Cookie based authentication system
cookie based session is StateFull. as here server needs track of active session,while on front end/client end a cookie is created that holds a session identifier.
you can secure your web api using cookie based authentication system. but in a very limited scope, because ,cookie based system doesn't work well, on native clients or suppose if your web api is going to be consumed by some other web api,
Token based authentication system
it is StateLess as server doesn't keep here the track of which token are issued or which users are log in.
Here server needs to verify only the validity of the token. so token based approach is more decupled than cokie based.
Sources
https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
Update Above(Auth0) link not working any more Updated Link
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/secure-net-microservices-web-applications/
Answer To Second Question
Yes you can implement cookie based authentication in spa by using OWIN Cookie Authentication middileware .
you can find more information regarding it on following link.
https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/
Hope above will help.
If you are going to have React and API in one domain, and the SPA would be the only client of API it may be recommended to use cookie based authentication with SameSite Cookies.
https://www.scottbrady91.com/OAuth/Cheat-Sheet-OAuth-for-Browser-Based-Applications
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/
(section same-domain apps)
longer post: https://blog.cdivilly.com/2020/06/10/oauth-browser-apps
I'm trying to authenticate my app users with their credentials used at the website
I managed to authenticate users via Xamarin.Auth to login via Google, Twitter... etc but could not figure out how to authenticate them via ASP.Net Identity provider.
any ideas or examples ?
Your problem is not a new one, and is one that will be easily fixed in the near future (see note below).
When you're authenticating with a provider like Google or Facebook, you're receiving a token that you can then use to send to the API. Unfortunately Asp.Net Identity does not do this out of the box. You can either configure your API to use JwtBearer tokens, or check out the Identity4 project along with their samples. Note that if you're using Asp.Net Identity you'll probably want a cross between Quickstart 6 and Quickstart 8 so that all of the necessary persistent stores are in your database.
NOTE: You might also want to follow the Templating Team's PR #700 which is adding token based auth in the new templates which will soon allow you to rapidly create new Api's with Token Based Authentication for your mobile apps.
I'm building a mobile application (that might also later become a web application). The server side is a ASP.NET MVC + Web API application and I'm thinking about ways how I could implement the service's user management and authentication.
How should I implement the registration/login screen in the app? Offer native app forms, that will send just API requests to the service or is it preferable to show a web browser component and display the website's login page and then extract a token after the user logs in? I see the first option is more user friendly, but the second one will let me change the login / registration page (like for example adding external authentication providers) without breaking older versions of the app.
My second question is regarding the external authentication providers. ASP.NET Identity has good support for them and it is quite possible to let users register using Facebook or some other OAuth2 provider. Does it make sense to add support for external authentication providers when I plan to expose the app's API publicly? Are there any reasons why that is not a good idea?
Your first option is best if you believe your users will trust you to manage their passwords. You make a secure call to your service, have the service produce a bearer token as the result. That would be an anonymous call. I used the answer from this question to get me going down that path:
Get IPrincipal from OAuth Bearer Token in OWIN
If your users are less likely to trust you with their credentials, then the web view and external provider is a good alternative. You would need to work with providers that support the "Implicit Grant Flow" since don't want to share the apps clientid and client secret on the mobile device. This approach involves using a web view to login in, and then capturing the token on the client uri fragment on the response. I think it is on a location header, but don't have a working example in front of me. Something like:
https://your.domain.com/#access_token = 8473987927394723943294
you would pass that token with each api call afterwards .
Good luck!
I am relatively new to uisng ADFS (in ASP.NET) which is what my company wants to use and just have a few basic questions about that:
Am I correct there is no explicit "Authorize" call you can do like with ASP.NET Membership Providers? Unless you on a domain it presents you with a login screen and once you enter credentials it does validation and returns back a token with claims information.
Can you configure some forms to allow anonymous access like you can do with Forms Authentication?
Thanks.
Yes, you can setup pages in your app that don't require authentication. It works exactly like you'd do with Forms Auth.
On #1: in a claims based model, your app relies on an external system to authenticate users and receives evidence that the user is valid in the form of a token. You can completely automate this (using WIF and config files), or you can explicitly trigger the authentication process. In any case, your app won't be responsible for validating legitimate users anymore. It is a responsibility that it delegates to the STS (e.g. ADFS). That's why apps are called "relying parties".
I'd suggest you read the first couple chapters of the A Guide to Claims based Identity for a better understanding of the underlying principles.