I'm trying to implement a way to restrict the usage of a token only once. After its first use, you must not be able to use it alright by tagging the token on its state with UsedAlready tag and Unused if its not yet used. How do I do that in apigee?. Currently I have the following condition to determine whether if the Token is used already or not.
<Step>
<Condition>(request.queryparam.state NotEquals accesstoken.state)</Condition>
<Name>RF-TokenAlreadyUsed</Name>
</Step>
Looking on my Tracetool though, apigee is throwing out that my accesstoken.state doesn't contain anything, why is that though?. My API proxy and policy for saving a default state on token creation seems to work fine anyway.
PS: Also I did the almost the same thing but using a non existing variable instead using the attribute to associate a token to a particular account. But doing the same thing with state with what I did with an attribute doesnt work. What am I doing wrong though?, am I using the state parameter of apigee right? , cuz state parameter is an optional parameter like scope and I want to make use of the state for token accesibility.
Turns out I was using the state wrong. A state should function like this as stated in this thread.
So in order for me to be able to do what I want to do is that I should add another attribute to the token so that I would know if the token is already used or not. It's not that I havent done a similar thing before using an attribute, rather I thought the use of state is for token accessibility.
Can you explain me why are you more worried about the token state? Until unless you store the token in cache, you will get a new token for your every request.
And you have a built-in policy in APIGEE that validates your token.
Even if you are storing the token in cache, you can set the expiry time for your token.
More over, the cache is used to reduce the traffic and reuse the token.
So I couldn't understand your objective, can you explain more.
#user2462133
To answer your question.
We want the token1 to be valid only only once and after that be invalid for next payment alright . But this token1 will be used for generating a new token2 to access the payment API again as the previously made token is for binding the account on first use. This new token2 will then have another state which will only be valid only once and after successful transaction, it will not be valid for another transaction again even if the token is not yet expired. For another payment, token1 will be called again and check if its still a valid token, and if so, create another token2 for another payment. But if this token1 is already expired. Then the user would have to bind his account again to our service by loggin in to his account (i.e facebook), do the OTP, etc. To be able to gain another token1 that will then only be used once for payment but multiple times for validating whether if the account is binded to our service or not.
Related
My application have to fetch data from external services with the usage of manually provided at profile/management by user api key & api secret.
I'd like to prevent a huge amount of retriving those necessary keys queries to database and persist it somewhere else (assuming that those keys won't be updated too frequently).
From my point of view it could be implemented with next options:
Use MemoryCache provider with SlidingExpiration;
Create a custom Claim and append it into existing Identity claims collection;
Please correct me if I'm wrong, but if I've realized it right - claim's information is a part of data, which is used for serialization/deserialization at frontend<->backend interaction (I'm not quite confident about it, but suppose that it's used within cookies & tokens).
Actually these keys are also required for a several background processes (message queue consumers or scheduled jobs for example).
Would you mind letting me know a proper way for persiting such protected and frequently used fields in an optimized way?
Thank you in advance.
When you login using one of SignInManager's sign-in methods, it sets a cookie on the browser with an access token in it. This cookie contains claims data. So in subsequent authorized requests, you can query the User.Claims field to access the required fields without making a trip to your datastore.
Now whether you choose to use claims or not totally depends on how often you need the API Key / Secret. Your claims are part of the access token. If sending the API key / Secret on every request is justified, claims is the ideal choice.
UPDATE:
Rather than decrypting the tokens at the frontend, it's better to send them to the frontend client along with the access token.
Incase you're not aware of IdentityServer4 or OpenIddict do check them out. It's probably got all that you need.
I am currently building one web application, and I consider to use Firebase auth and its database. My concern is that if user id is on browser, does it make any security issue?
For example, say that my user id is 12345, and I would like to show some information about user 12345 on a certain page. In order to move to the certain page that I can see user's information, I click some element (like a button), and go to the page. (Ex: https://localhost:9876 => https://localhost:9876/12345) In this case, the user id is visible, but I am not sure if this is reliable approach.
Thanks.
EDIT: I just noticed that security rules should be used thanks to Eric's comment. However, I am not 100% sure if the rule can be used for auth object too. For example, auth object is used to get user id, but using user id, is it possible for someone to obtain the user's email address which is stored in auth object? For instance, in the above example, someone might obtain user 12345's email address using user id, 12345.
The correct way to secure user related resources is via a Firebase ID token. Database/Storage rules already rely on this mechanism. You cannot just rely on the correct user ID being provided. That provides no security. Instead, before return restricted resources, you should check verify the ID token and trust only its content which includes the UID. FYI: the Firebase Admin SDKs already provide an API to verify an ID token.
Typically the way to pass the ID token (if you are not using real-time database), is as follows:
Single page app: you can call getIdToken() and then pass the latest ID token in the URL query parameter, post body or the header as you send an XHR request to your server.
Traditional website: you have to set a session cookie. The easiest way is to set the ID token as session cookie and keep updating it on expiration. On your backend, you will verify this before returning the user specific resource.
i've read all the tutorials and questions asked about the subject but they contradict one another
claims(userclaims and roleclaims) are serialised into a cookie (along with custom identity user properties you specify by overriding the principle factory) but they don't get queried, they're stored in a cookie, which mean that the more claims a user have, the more data will have to round trip between the server and browser
a custom identity user property by default don't get serialised but get queried from the database, so every time you need that data it query it from the database which is more work to do on the database on each request if you frequently query for it
so which is more efficient and which is safer
for instance
IsAdmin should be a role/claim? but then if someone stole the cookie, nah nah, the cookie already contains userid/username/securitystamp, so even if it's a property, the userid on the stolen cookie would query on the custom identity user property, or is there something that will prevent this cookie from working when stolen ?
another instance
if i've 20 property for the user (first name, last name, address 1, address 2, postal code, whatever the case may be), should i simply have the user wait a bit for a bigger slower cookie to be send back and forth or should i do all the work from the db using custom identity user
but then, if i remove or add a claim to the user, would it be updated on the next request if it doesn't get queried or is the security stamp validate that this cookie is still valid ?
cause at the Task AddClaimsAsync of the userstore of efcore it only add the claim to the dbset
i apologize i know this is many questions to ask but the resources on the matter are not that good and one can easily get lost reading the identity source
Rule of thumb - put frequently added items as a claim, everything else can live in DB and be queried on demand. I.e. address 1, address 2 can't be required on every request, so keep them in the DB.
On the other hand IsAdmin (should be a role anyway) I can imagine will be checked on every request, so it should be in the cookie without having to query the db.
If you afraid of your cookies getting stolen, don't show them to anyone! set up SecurityStampValidator to do frequent checks - like every 5 minutes. This basically updates the cookie with the fresh information from your database and changes the cookie. So even if the cookie is stolen, it will only work for 5 minutes.
I don't think the two statements contradict, it depends on your configuration. The second statement mentions "by default".
You do not need to store all information in claims nor do you need all the information all the time. If you want profile information, call the server once and store the information on the client, or get it when needed only.
The same counts for authorization, in case you want to show / hide elements based on permissions. This may include a tag called "IsAdmin". Authorization should be kept close to the resource.
If your client wants to refresh the information, just call the server. Claims are not updated during each request. In general, the user has to log out and log in again. So Claims are not flexible and therefor not really suitable for properties that can change (frequently).
As for safety, it doesn't really matter that the client can alter the information, it is for display only. It doesn't change the permission in the backend.
You can consider to add something like a display name to the properties, if you are showing that in every page. You can also consider to implement caching to limit database calls. In the end it really depends on your requirements.
As for stolen cookie, you'll need to implement additional security to your server to detect suspicious behaviour. You may want to include the ip address as claim. As for the admin, add security, e.g. filter by ip address and / or use an additional code which was send by email.
I'm using IdentityServer v4 to handle authorisation for my ASP.NET application, using Resource Owner flow.
I've implemented the IdentityServer4.Core.Services.IProfileService interface which has two methods, GetProfileDataAsync and IsActiveAsync.
When making a request to the token endpoint, the GetProfileDataAsync gets called as expected. We use this method to issue our claims.
However the IsActiveAsync method does not get called. I'd like to implement this method to determine whether the user is active in our database. At what point is this method supposed to get called?
The comment in the IdentityServer source (see below) suggests it should get called during token issuance, but the method isn't called when requesting a token. I suspect I'm missing something. Any help would be appreciated.
// Summary:
// This method gets called whenever identity server needs to determine
// if the user is valid or active (e.g. if the user's account has been
// deactivated since they logged in). (e.g. during token issuance or
// validation).
Task IsActiveAsync(IsActiveContext context);
Right now IsActiveAsync does not get called for resource owner password requests. I guess the assumption was that you wouldn't successfully authenticate a user if the user is inactive.
These details are not yet decided on - if you have a strong opinion on how this should work - please open an issue on github. We will lock down the API in late August.
I searched through similar questions but none seem to answer this particular concern:
Assuming I am building a simple oauth user login system, when the oauth flow is done, should I pass the obtained access token through GET query, such as /login/provider?access_token=xxxx (assuming HTTPS), or should I store it in the session and delete it when my REST api call are done (assuming HTTPS + Signed cookies)
From what I can see: session approach doesn't expose token to even the user himself, and prevent logfile from recording ?access_token=xxxx, appear to be the safer bet.
Are there reasons for choosing GET query? Does my argument apply to OAuth 1 token and secret as well?