I've been working in a POC with OpenIddict v3, assessing if it covers all the use cases in our currently IDServer.
The only use-case I don't find how to workaround, it's that we have symetric or asymetric keys configured per application, and with openiddict the signingkeys seems to be defined at server level (not per application). Yes, many keys can be configured, and ther are selected according to its own algorithim, but at server level.
I need control over the signingKeys used for signing and validating the tokens of a particular application, and that signingkey has to be different from one app to another.
I'm looking into "event handler model" but I don't sure if it's the best way to acomplish this task or there is another way.
In case, event-handlers, was the best way:
where I can find examples or documentation of each event.
would be these the events to take into account ¿?:
OpenIddictServerEvents.HandleTokenRequestContext (for genearating the token with the appropiate signingKey)
OpenIddictValidationEvents.ExtractCryptographyResponseContext (for getting the signingkey according to the app and validating the token with the correct signing-key application specific)
I would be very grateful if someone could point me in the right direction.
Thanks.
Related
Ok, so as per usual, MSDN is now an automatically generated blob of useless documents, so maybe the developers lurk around here and can explain this to me.
I created a custom Authentication scheme based off of the AuthenticationHandler<TOptions> base class. I have two questions regarding this:
How do I define the type to use in AuthenticationSchemeOptions.EventsType in order to consume authentication-related events?
If the loggerFactory object a required object? Can't I just pass null to it? I want to control my output. I guess I could test this one myself. If you want to answer, go ahead, otherwise I'll test it at some point.
But what I have no clue whatsoever is for question 1. I see the class JwtBearerEvents as a sample, but I have no idea if I should be creating one exactly like that, or in general, how does this event system works at all???? I am utterly confused.
Thank you.
P. S.: I don't think it is important, but just so you know, the custom authentication handler basically validates a JWT created by a federated API server whose signing keys can be queried to verify signature. So basically it is a handler that makes a web request (then caches the keys) and uses those keys to validate the token and extract the claim data of interest, finally creating a ClaimsPrincipal user out of said claims.
We want to make our API stateless.
Right now, the tokens for users are provided via 3rd party, upon login, and stored in the application memory.
As long as the token is in use, it is valid. Until it is idle for a configurable amount of time.
On 3rd party's side (the token provider) this token is valid for much longer (For example: A month on their side regardless of usage VS. 20 minutes of idle time on ours).
Meaning, each usage of this token updates the timestamp in the application memory.
As part of making our API stateless I've encountered a problem:
Assuming we will have more than one application and a load balancer,
how do i maintain the user management between 2 applications?
I know how to restore the users profile/details if the token isn't in the application memory (but still valid on 3rd party side), but i can't know the timestamp of it's last usage.
I think that i either have to sync the cache between my applications, or manage the users on another service.
I'm hoping that my explanation is clear enough.
My questions are:
What is the best practice for this issue?
Where can i find useful information regarding user management across multiple applications? I think that i'm struggling with key words in this case.
Thanks in advance
From the architectural point of view separate user manager is preferable. In this case you will never turn to your 3rd party token provider directly but do it via your own manager that stores tokens and the timestamps. This however will probably require a serious refactoring.
So, other solution that I can offer is probably using tool that provides sharing memory among processes and machines. For example you can use Hazelcast. It is very easy to start tool with very user-friendly API. If for example you store mapping from token to timestamp in map now the only thing you have to change is the place where you create map. Use the Hazelcast map factory instead of new HashMap<>() and your tokens will be magically distributed among your applications.
I'm building a single-page web application, fully based on RESTful API. I've seen several topics in that matter, but some things remain unclear for me.
I will need users to log in. Here are some of my ideas:
I can send e-mail and password to API and use basic auth. I'm not sure where should I keep password, should it be encrypted and if so: how?
Can I use built-in session system instead? Is it wrong to use cookies directly in the RESTful API? Why is it so popular to send credentials/keys to API itself instead of using cookies?
I thought about having one API key per user, return it in login action and keep it in localStorage. I guess it's not the greatest idea to have just one key per user?
Then, I came up with idea to have separate keys table and add random keys each time somebody logs in. On logout, the key would go away and no longer be valid. This is more secure than previous idea.
How is it solved in simple projects? I'd like to make it simple but not ridiculously inserure.
Please help.
The commonly approach is to use the header Authorization in REST. The state of the application must be on the client side with REST and shouldn'a be tied to a particularly client kind (browser with cookies)
I think that this link could be helpful:
Implementing authentication with tokens for RESTful applications : https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
There is also à great question to à similar question here : https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api
Hope it helps,
Thierry
I'm struggling with an issue here. I've searched repeatedly for answers, but have been unable to find the exact answer I'm looking for. I'm attempting to build a secure authentication method for a REST api. My question is, how do we handle a login for a REST api?
Since a REST api is meant to be stateless every time, does that mean we need to store the client's username/password on the client's end (perhaps hashed), and send it in with every request? I'd be much more comfortable using a system like authentication tokens that are created upon logging in the first time, but does that go against the basic rules of REST, since this technically creates a "state" on the server?
What is the best and most practical method to handle this? As I wrote earlier, I'm struggling to come up with an answer to this; maybe that is due to this problem not having a clear answer, but I honestly don't know.
Thanks in advance.
That's also my understanding of REST: clients send login/password to the server along with every request. The server has to authenticate the client based on this information only. With regard to the Hypermedia principle of REST, having a user logged in is not an application state, in my understanding.
We are building ASP.NET MVC app that is supposed to manage sport objects reservations (tennis courts, squash courts etc).
Users are not supposed to act only in scope of one club at the moment of interaction with app.
Navigation to the app should be like:
appname.com/clubName or
clubName.appname.com
Questions:
1. What would be the best way to persist the data about selected club. We have implemented storing in session (injecting information about the club durint app opening), but we read that using session is rather deprecated solution. We are using ApiController so in order to get the session we had to hack the routing (registering custom RouteHandler). Is session mechanism applicable for this problem?
var session = HttpContext.Current.Session;
if (session != null)
{
service.ClubName = session[CustomSessionKeys.ClubName.ToString()].ToString();
}
Is it good idea to use subdomains for our problem?
Many thanks in advance :)
Generally a web api works differently than a normal mvc app.
In an MVC application you would use a session cookie to make the internet act like a state machine. However, this is not what is generally done for web api's. In a web api, you provide some form of authentication (e.g. via the header authentication field).
But within a request you ofcourse want to to keep track of the current user, or in asp.net terms, the current principal.
We set the principle though a Delegation handler
HttpContext.Current.User = user;
If you want some more code on how this whole authentication is done, just let me know.
This was all serverside ofcourse, on the client side, you can keep any information you want in a session store. Although you might want to consider using the local storage in stead (depending on what semantics you want to give it). They both work in the same way.
You can consult W3C webstorage specification for the complete information on both of these.
Well you have many choices I guess!
Go with the route thing as you suggested, where you keep the club Id or name as part of the URL. I would go for this if I need the link to give more meaning to the user.
Cookie! yes, if the information is not sensitive store it in a cookie. In case this cookie is only to be accessed from server side, then don't forget to make it HttpOnly
Session. I agree with you, I wouldn't choose session unless the data was very sensitive and I needed to make it secure.