Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm new to wso2 API manager and can not understand the caching mechanism for API calls.
even though i read the related documentation here for hours but still confused.
can someone describe it?
i mean when i call an API from dev-portal with a token which generated for the application, what happens in the background?
how it checks if the token is valid or not and if its valid, how it cashes for next calls?!
thanks
There are two types of tokens in OAuth2, i.e JWT tokens and opaque tokens. In the latest version of API Manager you can't find the opaque token as it is now removed from the product.
JWT access tokens are self-contained access token and the gateway itself can validate the access token without reaching the key manager who issued the access token. In the JWT case, when you access an API with the JWT access token, the gateway first checks the cache whether the access token is available. If it is not available then only the gateway validates the JWT token and adds to the cache. Once the token is validated the request goes to the backend of the API and client gets the response. When the next request comes with that token, as the token is available in the cache, the gateway won't validate the token again.
In the opaque token case, when the request comes with the opaque access token, gateway first checks the cache and if it is not available, then gateway talks to the key manager and validate the access token and then adds to its cache. When the second request comes with the same access token, as the token is available in the cache, the gateway won't talk to the key manager.
When you make a call the generated access token will be cached. That's how generally it works. Go through the following documentation where it describes the configurations related to WSO2 APIM. By going through the part which explains cache mechanisms you will be able to get a proper understanding.
https://apim.docs.wso2.com/en/next/reference/config-catalog/#gateway-token-cache
Related
I have a doubt regarding the jwt token validation done by the REST api and was not able to find a simple yes/no answer. Assume that everything is being transferred over HTTPS.
I have the following setup
React app
REST API
AWS Cognito that handles the user registration/login
When a user wants to login, then the React app would call the AWS Cognito api and validate the credentials. If valid, Cognito will send back a jwt token (that will contain the necessary meta data) that can be passed to the REST API. Now I see two options
the backend verifies that the jwt token was not altered using the rfc spec. If valid, the api extracts the necessary meta data and continues to process the request
The backend verifies the validity of the jwt token, but also calls the Cognito service to verify the metadata in the token.
I think that since everything is handled over HTTPS and the fact that its hard create a valid token then the first point is enough. There is no need to have an extra call over the wire. Am I wrong ?
Found the following question from softwareengineering.stackexchange.com which pretty much answers my question. Link
The local validation of the JWT token is enough when the token was created with asymmetric encryption.
I am starting to work on an authentication system for an angular 2 Single Page Application using django-rest framework as back-end. I'd also like to have some kind of "remember me" functionality that is going to keep users logged in for a certain amount of time.
From what I have read so far, it seems that the best authentication method for this kind of Angular 2 SPA/REST API is using jwt (json web token). For jwt authentication, I looked at the django-rest-framework-jwt (https://github.com/GetBlimp/django-rest-framework-jwt).
The problem that I see is that the token needs to have a short life span (few minutes to a few hours...) in order to minimize security issues if the token get stolen. The token now needs to be refreshed frequently to avoid the user from being disconnected while using the application. In this case, a "remember me" functionality is posing problem since the token have a short life span.
I thought about a solution involving a second token that would serve as a refresh token. It would be opaque, have a longer life span and would contain information specific to the user (ip address or something like that) so that if it get stolen, the information specific to the user being different would render this refresh token invalid.
So here are my questions:
1- I would like to know if they are existing solutions addressing this problem. As any security/authentication issues, I prefer to rely on well tested solutions to avoid getting my API compromised.
2- Would the refresh token based on specific user infos be a good idea?
3- Any other ideas how I could implement what I want?
For your situation, you really need a way to store issued tokens.
I always use an OAuth2.0 server setup that manages the auth and returns tokens the OAuth setup uses a database to manage everything so it's easy to manage and revoke tokens.
The database schema would be like this http://imgur.com/a/oRbP2 the problem with using just JWT without any management over the issued tokens with long expiration you have that security issue of not being able to revoke easily.
I would advise against including any such thing as a password in the JWT and requiring them to change it what if they use that password everywhere, then they would have to change that everywhere.
Updated from comments
Sessions Authentication use session_id which most the time is stored in a cookie and this is attached to every outgoing request. It is stateful. It is nothing more than a unique identifier that associates a user account that the server has in memory/database. For example, this can course problems when running multiple servers/instances when scaling your infrastructure.
Token Authentication no session is persisted on the server so this means it is stateless. It normally uses the header Authorization: Bearer REPLACE-WITH-TOKEN . This means that this token can be passed to multiple different servers/instances because the authentication is not limited to the server that you initiated the authentication on. This helps with scaling your infrastructure. Tokens can also be passed to other clients.
RESTful API's are stateless so there must not be a session state stored on the server. Instead, it must the handled entirely by the client so that's why token authentication is used.
I had the exact problem when trying to use JWT with an application that needed a lot more than JWT was designed for. OAuth2.0 has a lot more options that I believe are necessary to meet your requirement in the safest manner possible and even features that you may find very useful in the future as your Application may grow and need more features with regards authentication.
This is a problem we are confronted with today. I looked online as much as I can before deciding to ask the question here.
The question is, when a user makes a "Access Token Request" with a username/password, should the Access Token response contain "user-id" field?
The OAuth 2.0 spec says there can be an extra field (search for "example_parameter" in the spec) as part of the access token response. Can this extra field be user-id?
However, Many of the companies like facebook/google/twitter does not provide user-id as part of the access token response. User-id is provided as part of the validate token response.
What are the reasons for not providing user-id as part of the Access Token response? Why do we have to make another call (an extra round trip) if we need a user-id? What are the consequences of providing user-id as part of the Access Token response?
Most applications don't want to leak their user-ids to the UI layer. It is generally considered bad practice. If you send the userid to the UI layer, the UI will have the ability to request information about that UserId, and get information about it back...
This presents a security issue, as the client can generally modify these calls to get information about other UserIDs... If you are going to authenticate each call each time to validate that the token is bound to that user id, then it likely is a waste to have the client pass the userid itself, you are already doing the lookup, so you might as well keep the data internal to the service.
This also sets you up nicely to change your concept of a UserId in the future, maybe changing it to be group id, or an email address instead of the database userid...
Oauth2.0 is an authorisation framework and doesn't deal with user authentication.
The question is, when a user makes a "Access Token Request" with a
username/password, should the Access Token response contain "user-id"
field? In this context the resource
It's really a client requesting an access token and in many cases a client doesn't want to know about the id of the resource owner it just wants a token to allow it it call an endpoint on the resource server. The resource server can identity the user from the contents of the access token.
OpenID Connect can be used to extend OAuth2.0 to include an ID token. This gives basic user info in a standard format without the need to call a further endpoint.
An access token is a normally a bearer token that allows you to call an API. In OpenID Connect, you use the access token to call an api called the user_info endpoint, which returns a JSON object that contains information about the person, like first name, last name, etc. If you are looking for a free open source central authentication server that supports OAuth2, you should look at the Gluu Server http://gluu.org
Actors
Front-end (fat client-side Javascript application) which has Facebook access token.
Back-end which 100% relies on OAuth2 authentication. All requests need to be authenticated via Facebook.
To mutate user data on the back-end, I require user to be logged in via Facebook. Ideally, with every request, I would know the Facebook's user ID (the one that graph.facebook.com/me provides).
Question 1
Is there a way to get whatever graph.facebook.com/me returns to be signed, so I don't have to call Facebook to verify it with every request, nor store state in my backend?
Situation 2
If the answer to Question 1 is "no", it means I have to invent my own. I am thinking of the following:
The user sends the access token to the backend.
Backend calls token debug API, signs the result with my key, and sends back to the client.
Every time client does a request, it includes the previously-included blob.
Upon every incoming request to the backend, it verifies the signature, which, if matches, means that the request wasn't tampered with and I can trust it is coming from the previously-verified token.
Question 2
If I employ this scheme (sign the answer from Facebook and send it upon every request), how can I safely implement this? Are there resources I could read up which would tell me:
Things to be cautious about with this scheme.
Which signature algorithm to use, how to safely verify the signatures.
How to avoid common types of attacks and stupid mistakes.
Thanks!
It's not really clear what exactly you want to do, but I think you should have a look at the docs at
https://developers.facebook.com/docs/graph-api/securing-requests
Quote:
Graph API calls can be made from clients or from your server on behalf of clients. Calls from a server can be better secured by adding a parameter called appsecret_proof.
Access tokens are portable. It's possible to take an access token generated on a client by Facebook's SDK, send it to a server and then make calls from that server on behalf of the person. An access token can also be stolen by malicious software on a person's computer or a man in the middle attack. Then that access token can be used from an entirely different system that's not the client and not your server, generating spam or stealing data.
You can prevent this by adding the appsecret_proof parameter to every API call from a server and enabling the setting to require proof on all calls. This prevents bad guys from making API calls with your access tokens from their servers. If you're using the official PHP SDK, the appsecret_proof parameter is automatically added.
The Twitter OAuth 1.0a flow requires authenticated request token to be exchanged with access token at consumer or client side after user has authenticated.
The problem that I'm facing is that generating access token needs authenticated request token, request token secret and verifier but the response from the oauth/authentication api doesn't have request token secret. So how do I temporarily save request token secret from oauth/request_token api call so that I can use it in oauth/access_token api call.
I found some solutions from my explorations like Running a Cache server (Memcached, Redis) or using django session feature. But they all seem to be overkill for this task.
I hope to find a simpler solution.
I'm sure you long ago figured this out, but just for future goolers: I decided to a go a more low tech route and create an OAuth token class which includes fields for the fetched and access token. Basically I take the fetched token, store it, then recall it when accessing (as it's in a different view) and then save the access token. Once (if) that's successful than I delete the fetched token.
There's likely a more glamorous way to do this, but if you're clever with your naming convention you can easily keep them straight (i.e. add a CharField for provider and just save the fetched token as twitter_fetched, and the access token as just twitter).
This has the added benefit of allowing you to create an OAuth1 or OAuth1Session from the stored access token.