I have a little question because I am trying to understand the notion of authentication server. I saw lot of diagram explaining for example oauth. But there is something I do not understand.
It is the validation of the token to let access to the resource server.
I made a little diagram to explain where is my question.
Thanks a lot for your answer :)
Have a nice day
There are basically two options:
Check the authorization server to see if the token is valid.
Issue self-validating tokens (using cryptographic techniques) such that the resource server can quickly determine the validity of the token.
I believe that number 2 is far more common, because it's capable of much better performance.
Here is a good article laying out the pros and cons of the two approaches. Their performance summary:
The self-contained + RSA signed access tokens emerge as the clear winner from this benchmark, by a factor of at least ten.
No, Resource Server should be able to accept (decrypt and validate expiration, roles, ...) the access tokens issued by the Authorization Server and respond with the protected resource if the the access token is valid.
Check this link.
Related
I have always opt for having jwt over session because of the less over head in the backend side (keeping in mind that it all depends on the use case) but the major issue I am having with it is the invalidation of the token, for an example : in case of the user being deactivated, the relevant jwt would still be valid until it gets expired. Is there anyway to overcome this issue in a cost effective manner ?
PS - however I saw the term " revoking JWT " in the cookbook section on the featherjs
framework. but its still looks like they are using redis as a lookup which in turns make it inherit drawback of using sessions.
Once a JWT is issued it is valid for as long as the exp claim value. You can't revoke a JWT, it's not how JWTs are meant to work.
As you pointed, out there are ways of mimicking the behaviour of revocation, but you need two things for that:
you need to have a database with information about which tokens are revoked
you have to make sure that whenever you consume the token you check online with the database.
There is no other way to do that.
If you really have a need to revoke JWTs it means that you need sessions, and you shouldn't be using JWTs for that. You can have a look at this article to learn why. If you decide to stick to JWTs, have a look at this best practices article I wrote to know what to watch for.
I have two questions, really. I'm learning authorization in ASP.NET Core using the OAuth scheme for my company's authority. The thing is, on the final (3rd) leg, requesting a token, I need to authenticate the client (client id/client secret) using basic authentication (as per RFC 6749/2.3.1) but from what I have seen from the traffic client credentials are sent in the body instead.
I have a very hard time finding good documentation on the AuthenticstionBuilder.AddOAuth extension method so my first question is for tips where I might find a proper walkthrough that explains how to use the options and the four events supported? What I have found is people explaining how to set it up for this or that authority (such as GitHub, Facebook etc.) but none explains how the scheme implementation is designed. As a last resort I will have to check out the source code but if anyone can provide some links to a good explanatory walkthrough I would really appreciate it.
My second question is if there is a way to use Basic Auth for obtaining the token, as I describe above? I assumed there would have been an event where I could do that but my experiments indicates the three available events aren't suited for this.
I am a student learning about cryptography. After searching online, I am still unable to find an answer to my question. I am wondering how to store a session ID securely for an ecommerce website. If it is possible, how so? Please do explain it in Layman's term. Looking forward to your helpful answers.
Cheers
Session IDs are usually just a random (opaque) identifier that is passed between the client and the server. The server uses the identifier to look up state information (e.g. current cart content) in the database.
As a practical matter, you have to trust that the client will protect the session id, as once you send it to them, it becomes a static token -- no amount of cryptography can fix the fact that anyone can present a session id and then pretend to be the user.
There are some things that you can do to mitigate issues:
ensure you are using a "secure enough" random generator to build the
token
make sure the transmission of the token is as secure as possible against eavesdropping or client-side theft (e.g. use SSL, httponly and secure cookie flags)
Give the token a reasonable timeout, and require the user to request a new token periodically using e.g. a refresh token or re-login.
A lot of thought has gone in to how this can work practically - have a look at the OAuth2 / OpenID Connect protocols.
Can I use Attribute Based Encryption (like CP-ABE scheme) and Oauth 2.0 to implement the Authorization, Confidentiality and Authentication (i.e. with FB, Google, Twitter etc.) in a web-application ?
Is there any example or framework ?
Is there any suggestion to use ABE with Oauth ?
Thanks
It doesn't make much sense to use OAUTH with CP-ABE. Those materials are on different levels. In fact, the OAUTH standard doesn't mention encryption at all, it just requires HTTPS without specifying a SSL/TLS version or cipher suite. Also OAUTH is concerned with resource access, thus authorization (but often misused to authenticate objects).
From the CP-ABE perspective there is no logic either. The idea of PKI is to establish a secure and trusted channel, not to do authentication or authorization.
If I have misunderstood the question, please clarity.
Update
Yes it is possible, but still subject to research, and therefore I wouldn't put too much trust in the method yet. What the paper describes it possible, but I doubt it will be used on large scale.
I am not an expert but want to comment here.
The key feature of OAuth2 is to facilitate authorization
The key feature of ABE is to facilitate encryption using attributes that helps in achieving privacy.
[for confidentiality and authentication, explore something else].
Since authorization and encryption/privacy are different aspects of security, they can be combined in innovative ways [such as this].
Background: I am trying to create an SMS API service. The developers have a Dev ID, and an API secret key assigned to their developer account. The developers will be creating apps which will issue calls to my API. But the application issuing the call must be verified first.
Issue: The main issue i have is with authentication. I read up on OAuth and pretty much uderstood it. I read through this presentation (Slide 71-82). All OAuth articles talk about the OAuth 'dance' or the 'love triangle'. My problem seems to be, that i dont see a proper triangle in my case. Or, a better way to put it would be, the triangle doesn't seem to be complete.
What i mean by that is, in the case of lets say, LinkedIn, trying to make some app which helps users associate their LinkedIn acc with twitter, OAuth makes complete sense. Because LinkedIn needs to get resources from twitter ON THE USERS BEHALF (Cuz the user HAS A TWITTER ACCOUNT). In my case, only the consumer has a developer account registered with my service. The end-user doesn't have any credentials for the consumer to ask on behalf of. So how can i implement Oauth? So what will the consumer ask the provider? Will it only state that "watch out, here i come?". Cuz that seems pretty pointless unless its asking for a request token in exchange for an access token. But in this case since the end user doesnt even have an account, the steps seem useless.
So, i cant figure out how to go about this authentication issue. Ive tried thinking about using php sessions so it can help me associate a token with the particular client who is using the API. But the REST/OAUTH purists seem to disagree on the usage of sessions in authentication. They claim that OAuth is a standard which has proven itself and that is what I should use instead of coming up with my own obscure schemes.
From your description it seem that you're in a two party scenario only (developers write code which accesses your API on their own behalf, not on behalf of an end-user), so that means indeed that doing the full 3-legged oAuth scenario isn't needed.
You could use pretty much any authentication scheme and that would work (API Keys, other oAuth grant types [see below] or even ID/Secret combinations. In the oAuth world:
Look at the other oAuth 2.0 Grant types: especially resource owner PW grants - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.3. It's slightly better than username-password because the PW isn't passed across the channel all the time (it passes once though) and it assumes the developer writing the code is the owner of the credentials.
Look at oAuth v1.0: this different in various ways to v2.0 but one feature it does have which some people like is the way tokens are used - which is rather than being passed across the wire they are used to generate a hash in the client and then the hash is verified on the server side. It's more expensive and complex than checking a key but it's less prone to attack.
In the non-oAuth world, if it's primarily a server resource used by developers directly, an ID/Secret or API-Key pattern is probably more than sufficient and it's much easier to implement for your developers.
Re: oAuth - if you're doing any type of user auth then definitely stick with the standard - the stuff is complex and having libraries out there really helps. If it's developer-api you likely don't need to go that far.
If you want the API to be secure in an ideal world anything which requires the security token to pass across the gaps should be secured using SSL, especially if that client code could be running on a mobile device or laptop which might communicate over wireless. If this isn't the case, someone could jump in an copy a token from one of the devs.
The only one of the protocols above that avoids this is the oAuth 1.0 variation since the secret never leaves the client but is used to hash instead. But it's complex. Last one to look at is the Amazon AWS pattern which does hashing similar to oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html and people emulate quite a bit.