I have a uwp application and an ASP Core server application. I want to perform Get and Post requests to the ASP server and I want to perform authorization on the server side.
According to the team, they don't want you to use Basic authentication nor seems there be a way to perform digest Authentication. I don't want my client app to show the user any ui: it should be able to perform a secure request by itself.
So: what is the most easy and secure protocol to use to perform api requests from UWP to an ASP Core server?
what is the most easy and secure protocol to use to perform api requests from UWP to an ASP Core server?
I'd like to say this is a open question and I will give some suggestions and hope it can help you. Basic authentication and digest authentication you mentioned are defined in rfc2617. Since you don't want to use them, besides HTTP Basic/Digest you may have other choices like OAuth, HMAC and Azure API Management.
Since you don't want the user to input username and password, to request an access token for authentication may meet your requirements. So I recommend you to use OAuth authentication which is popular. More details about OAuth2.0 please reference this. But it requires OAuth server, it may not be a easiest way.
Another way you can apply HMAC authentication to secure Web Api. HMAC authentication uses a secret key for each consumer. For more details about HMAC authentication please reference this thread. For more details about HMAC in uwp please reference MACs, hashes, and signatures.
You can also use third party tools from Azure. Azure API management can help secure and optimize your APIs. Details please reference the Publishing and securing access to REST APIs in uwp.
Related
Hi I am building a centralized authentication structure for all our applications in our intranet.
I have tried using a Jwt Web Api.
I have tried Identity Server 4 OpenConnect
And now i found out Cookie Sharing from Microsoft docs
https://learn.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2
I can't decide even after reading so many articles already which one should i implement.
The cookie sharing sounds very simple to do, I downloaded the sample and it worked right out of the box.
The identity Server 4 samples all have some problem that i can't run. Some functions like log out won't work or only works on one end.
The Jwt Web Api wasn't very hard to implement but still requires to thinker a bit to get claims from the token and then implement token refresh.
The cookie sharing i just found out but i'm still open for more alternatives or pros and cons each of these.
I also heard about OWIN but still don't understand exactly what it is
AFAIK
Cookie Sharing
If all of your applications are on the intranet and are all made using the dot net stack. It makes sense to take advantage of the sharing cookies. I previously had success implementing SSO using this strategy where the main login would be an old web forms application and it would authorise a dotnet core app.
Pros: You are using the Microsoft stack, easy to setup.
Cons: You are locked to using the Microsoft stack. Falls over if you want to use with native/js applications.
IdentityServer4
Having experimented quite a bit with this library, this is an abstraction of the OAuth2 and OpenIdConnect protocols, essentially authentication and authorisation using jwt tokens. IdentityServer4 allows you to specify your authority (AS => Authentication Server) which is handles authenticating clients (your other applications be it .net, js or native). The token that the AS gives the clients are then used to determine if the client has access to the an API. You get to specify which clients can access which api's and how much of it can they access based on Claims. It is possible to convert Active Directory groups into claims and authorise by that level.
Pros: Really good abstraction they simplify a big part of the process. You can secure any type of client (js/native/.net).
Cons: You still have to learn OAuth2 & OpenIdConnect specs, which can take quite some time. You'll probably endup writing quite a bit of configuration depending on how big the network of apps that you are trying to secure.
JWT Middleware
This just allows the api to authorize tokens against an authority, and it doesn't really provide the "centralized authentication structure", you will have to handle alot of the flow setup your self. generally just a watered down version of IS4.
Pros: fast and simple way to secure an api to an already existing Authority.
Cons: Doesn't allow you to create a Authentication Server.
Summary
I'd say go with Cookie Sharing if you don't plan on securing native apps or js apps.
If you are setting up token based authentication read below.
Go with IdentityServer4 for long term flexible solution and if you have time to learn how to use it and set it up.
if you have an authority and don't mind doing a bit of setup go with JWT Middleware, this will be a bit more flexible than Cookie Sharing.
I am implementing notifications within an action. I am able to register users. However, I am not able to figure out how to do the push notification.
As the sample code uses the SDK, I am now stuck at the part "Exchange key for an access token" found in this documentation.
Is it possible to do this without the SDK? using a rest service?
Yes... but...
There is a REST service that does this, in fact, the library ultimately calls it. It is the standard OAuth2 token exchange endpoint at https://www.googleapis.com/oauth2/v4/token. The catch is building the JWT that you can pass to this service. To quote Google's page on the subject:
Although your application can complete these tasks by directly
interacting with the OAuth 2.0 system using HTTP, the mechanics of
server-to-server authentication interactions require applications to
create and cryptographically sign JSON Web Tokens (JWTs), and it's
easy to make serious errors that can have a severe impact on the
security of your application.
For this reason, we strongly encourage you to use libraries, such as
the Google APIs client libraries, that abstract the cryptography away
from your application code.
In short, if you want to do this, you need to:
Create a JSON Web Token (JWT) which includes a header, a claim set, and a signature.
Request an access token from the Google OAuth 2.0 Authorization Server.
Handle the JSON response to get the access token.
Keep track of the lifespan of the access token and, when it expires and you need an access token, repeat steps 1-4.
Details are at
Using OAuth 2.0 for Server to Server Applications
I'm not familiar with C# libraries, however I've been told that Google's C# Client Library seems to support it, and the high level documentation for ServiceAccountCredential appears to be able to generate auth tokens from the credentials.
Our project is using SignalR over ASP.NET OWIN (full framework), and clients are mobile apps based on Xamarin. Authentication is done based on JWT. It is needed that we protect SignalR hubs against anonymous access, then find out user name of the connection.
Is it possible to SignalR to work with JWT? If yes, how?
SignalR's own protection is based on cookies not JWT. Also we can't afford to use query strings to pass the token due to deployment that is not HTTPS.
I'm very new to the identity management world, so please spare me. :)
What I would like to do, is to have multiple client (MVC) applications that talk to a single Web API application to authenticate their users against. In that Web API application, I would like to use ASP.NET Identity to talk to a database with users.
That way, I could use SSO for the client applications (I guess).
Does that make sense? Could someone help me on my way to implement this (links are also welcome of course)?
I don't know if IdentityServer could help me with what I want?
And as a side question: when I could implement this the way I would like to, how do I deal with the same-origin policy?
Thank you for all the help. :)
I did some research myself during the last few months and I learnt a lot about the identity management stuff. Many of that also thanks to the guys from IdentityServer (and their other projects).
What I finally did was the following (very briefly):
IdentityServer is used as a provider for all client applications. The cookie and OIDC middleware are used.
I used the ASP.NET Identity user service to store the users in an SQL Server database. (The IdentityServer configuration is by the way also stored in a database.)
I set up a Web API service that uses the ASP.NET Identity user manager for user configuration (change password, create new users, ...). It uses bearer authentication with the application with IdentityServer as provider.
As a side note, IdentityManager is used as an internal admin tool to manage all the users.
If anyone is looking for some help setting up his / her identity management system (and thinks I can help): please ask. ;)
Many articles on active profile e.g. Federated Security: How to setup and call a WCF service secured by ADFS 2.0. But that article assumes you want to use AD?
I'm guessing you want to use ASP.NET Identity for the provisioning?
IdentityServer OOTB supports a SQL DB and has basic user provisioning built in. It allows users to authenticate against the DB and supports WIF.
This scenario is also close to what you need, take a look at the answers:
How to implement an OWIN Authentication server with a MVC Web Api content server and an Android end-user apk
I also recommend reading this article:
Decouple OWIN Authorization Server from Resource Server
I built a wcf rest service with form authentication. All the settings are set in config file. This service needs to be consumed by android client. So can any body please tell me how to send the request with log in credential to the rest service which is implemented using forms authentication.
Note: I know by implementing custom login service method we can validate the client and pass the cookie for the wcf rest method to authenticate.
I am looking for different solution like in single request we pass the credentials it validates the user with membership and gives the response. Please let us know if u need any further information.
This is a very broad question, so it will be difficult to answer completely. For the WCF side, you can follow this: How to Consume WCF Service with Android. The idea is to return a token, or session, ID when the user successfully authenticates in the system, and each subsequent request uses this token to identify itself. That approach uses SOAP, but you can also use REST too, which REST may be easier to consume in an Android client (REST worked great for me).
See this post, Need advice on authentication for android client connecting to the WCF Rest setup, for more guidance on the setup too. When I setup my authentication mechanism, I did a lot of research online to figure out the best approach to take. A lot of people mentioned just use OAuth 2, and make sure you are using HTTPS communication. So if you can use OAuth or Facebook/Twitter/Google+ for authenticating, that would be a good approach and take a lot of the headaches away.