I have an application running on this following structure:
My Actor is PKCE SPA application holding an access token, made with IdentityServer 4 redirection flow. My Frontend website allow this access token. Some of the Frontend website operation is calling the API server logics.
Right now I have an endpoint in the API server that requires the caller to be Frontend website client. But, I also want require a user content, the Actor in this case, which represent the user asking for the server.
Is it possible to supply two access token (one for the OpenId client, other for the customer)? Or I miss a better solution?
Related
I'm creating a centralized authentication system for multiple mobile applications. Its architecture is based on the OpenID Connect flow through the use of OAuth2.0 with IdentityServer4 on ASP.NET Core Identity.
I have researched a lot and in the main implementations with the Authorization Code Flow observed there is always the redirection of the user from the mobile app UI to the server web views, to allow the management of its profile.
This is very uncomfortable, because it significantly compromises the UX. I would like the user to be able to register and authenticate himself directly from the app interface without any redirection that involves opening a browser. Is there a way to do this with only API calls, from the client backend to the centralized authorization server?
You can use the Resource Owner Password Credentials grant type where you can pass the user credentials to the token endpoint and receive an access token. But usage of the ROPC grant type is highly discouraged as you can read in this blog post from Scott Brady, one of the creators of Identity Server.
What I can propose to you is to use Authorization Code flow to login the user and get access token for them, and then creating your custom API endpoints on identity server for user management. More on custom api endpoints here
I'm trying to get information how to authenticate and authorize a user from a backend WCF service using OpenID Connect configuration rather than using a client application (like Angular / .Net MVC web application).
Can this be achieved using "Authorization Code Flow"?
If yes, could one please guide me, how this can be achieved as we will not be able to configure the re-direction URL for a backend service to get the access token.
If not, could one please tell me how this can be achieved? I did read that this can be achieved by back channel communication (i.e. https://openid.net/specs/openid-connect-backchannel-1_0.html. If one can help me with the tutorial document that is available in internet that would be really helpful.
The link you mention is about back-channel logout: a communication from your OpenID provider toward your backend to notify your backend of a user ending her/his session at the OpenID provider. I do not see how this could be used to authenticate a user.
It feels somewhat odd that you are trying to authenticate a user from a backend service. The whole idea behind OAuth and OpenID is to pass a credential allow with your request to the backend. The backend must verify that credential but should not involve in gathering and issuing that credential, it should rely on a trusted party (the OpenID provider) to issue those credentials.
I am developing a web api service which will be consumed by asp.net mvc web application and mobile apps (android and ios). My database and web api will be hosted on same server. I want to implement authentication for web api (token based). My database has a table for storing user credentials. I will have to use this database to validate the credentials when the user logs in.
Came across a few articles which suggest owin and identity server. I am confused on how to proceed and need some help in understanding a better approach.
you can simply implement the token base authentication
when user is login to the system send the random token code
cash it in the client side
when client side making request to the server send the token with the request header
validate the token and accept request or reject
simple way :)
I'm posting this in the hope of receiving some feedback/advice and information on something I've been struggling with the last few days. To start I'll give a quick breakdown of the project.
There are 2 applications in the solution:
WebAPI resource & authorization server - Uses OWIN (hosted in IIS) and ASP.NET Identity to issue an authentication token on a correct login and then allow requests to the various controllers.
MVC client application - Has no authorization as of yet (until I figure it out) but will make calls to the WebAPI resource server to get all data. These calls will only ever be made from actions of the controllers in the client app, no client side AJAX calls.
The client application doesn't have it's own datasource. All information is stored in a database which the WebAPI service has access to, so essentially if they provide the correct credentials and the client app receives a bearer token I need to deliver a way for the application to see them as authorized.
What's the best way to handle this?
Is it possible to configure OWIN on the client side to use the OAuth
settings of the server? Am I barking up the wrong tree and will I need to just use HTTPClients?
Could I deserialize the bearer token and store it in session, and
then write my own authorization providers to check these on the client side?
My initial concerns are I'm abusing Bearer Tokens and trying to cobble them into a solution which isn't ideal. All examples of external authorization I've found so far usually involve making calls to providers hosted by Google/Facebook/Twitter to check the user is who they say they are, and then moves on to creating a user record in their system. My application can't do this.
In regards to security I was planning to introduce filters which would validate the request has came from the client application by providing an identifier and secret, along with IP validation.
I realize this may be a bit open ended, but I'd appreciate any advice. The scope of the project is that the web service is the only thing to have access to the database. The MVC client application will be hosted on a different server, and the service will only accept requests from said client application.
You don't need to access the data source in your MVC app to validate the bearer token. Basically, you can do it in the following way,
MVC app requests access_token from webapi and passes it to the UI client (let's say a browser).
Browser stores the access_token in a cookie/localstorage and sends them to the MVC app for all subsequent requests.
Create an ActionFilter in the MVC app to validate if the request from the browser has the token supplied in the header. If not, reject the request.
MVC app passes the access_token in the Authorization header to the webapi.
Use HTTPS for all communications (between MVC app <-> Client and MVC app <-> WebAPI)
You can further obfuscate or encrypt the access_token you get from the WebAPI on the MVC app side for additional security but then you will have to send the decrypted version back to the WebAPI.
I realize that my answer is a bit late, but maybe it helps other people:
The bearer token that you get from the API has a list of claims encrypted that only the API can decrypt. I assume you need to have these claims on the MVC application as well so you can restrict resources on the client.
So, what I have done was to first get token. After you get it, you make another request to the API resource api/me/claims to get the list of readable claims on the client. Based on this list you can allow access to resources in your MVC CLient Application using a custom claims based Authorize attribute. Also, you can store the claims in a cookie in the client session. Below is the code for the API controller to get the Claims.
[RoutePrefix("api/me/claims")]
public class ClaimsController : BaseApiController
{
[Authorize]
[Route("")]
public IHttpActionResult GetClaims()
{
var identity = User.Identity as ClaimsIdentity;
var claims = from c in identity.Claims
select new
{
subject = c.Subject.Name,
type = c.Type,
value = c.Value
};
return Ok(claims);
}
}
The idea is to reconstruct the ClaimsIdentity object of the logged User on the Client side and maybe add it to the session.
The token is not enough. You might risk getting a Not Authorized response from the API on a resource that you have made visible for the user in the MVC Client Application. Needles to say that is recommended to use HTTPS for all requests.
This is what I wish to achieve:
My ASP.NET web service is hosted on a server called //service. I want to control access to the web service by server and by application as well. What I mean here is if I have two ASP.NET web applications (app1 and app2) hosted on a server called //web1 and I only want //web1/app1 to be able to call the web service. I know that I can grant access to the IP address of //web1 but that would allow both //web1/app1 and //web1/app2 access to the web service.
I am thinking about using an SSL certificate as I don't want the web application to handle the login/password. on //service, I will grant access to the ip of //web1 and map a client certificate from //web1 to a windows account and this will allow only applications from //web1 to access. But then how do I further control the access to only //web1/app1?
You can use standard HTTP Authentication to control which applications have access to your web service.
Credentials are passed in the Authorization header with each request. Every web service client (i.e. //web1/app1) should have its own credentials, so if //web1/app2 tried to connect to the web service without providing recognized credentials, it would be denied access.
I recommend using SSL to encrypt all traffic, so that authentication information and other sensitive data is secure.
Here are a few articles that may be helpful:
HTTP Security and ASP.NET Web Services (see Authentication section)
Authentication in ASP.NET Web Services
Good luck!
Not really.
A certificate secures the transmission between the client and server domain. It doesn't really work to have multiple certificates for multiple subdirectories.
What you'd want to do is to create a login service that returns a token. You then use that token to manage the session on the server side and the client uses it along with every subsequent request to access and execute the available services. (can this token access this webservice? t/f)
You're going to have to give the client access to some sort of credentials. Whether that is a certificate exchange or a user/pass you're going to have to figure out who the client actually is.