How to use access-token concept that is used in facebook.
1)Can we implement same concept in ASP.NET based web application?
2)Can we use this concept in adding security to access in webservice ASMX and WCF ?
After long time I have found the answer I have posted.
If I am wrong please review my answer.
1) In Facebook server flow authentication when user is successfully authenticated Facebook generates authorization code parameter name as code.
2)In second step using all this parameter authorization code with client _ secret ,client _ id , redirect _ uri , state call Webrequest or call service if success then response have two parameter accessToken ,expires _ in.
3) This accessToken is used for getting userinfo like firstname,lastname,birthday etc with specified scope.
And this is general scenario that is used with WCF and ASMX webservice by storing valid accessToken to safe place or further use.
1) Access token is just a hash from some parameters, e.g.:
MD5(userName, userMail, someSalt, someOtherStuff)
So you can implement it for sure the way you like it. But better if it contains some secret information that can be retrived only by current user
2) Yes you can. As social networks like facebook do it:
there's some application secret key that is known on a server side (where your service runs), and some signature that can be retrieved from facebook api for some app and user and some other information.
Your facebook app gets that signature, it can use it to make hashsum with other parameters like userLogin, application scores or w/e else. Sends it to server.
On a server side you generate signature same way as your appliaction do based on parameters. If signatures are same request is valid. If know - someone is trying to do dirty things :)
Related
My current setup is the following:
Single Page Application with Vue
Rest Backend
The SPA has social login functionality. It uses the authorization code flow with PKCE to retrieve:
Access Token / Refresh Token
ID-Token
As it is an SPA, the information is stored in local storage and therefore not 100% secure.
But how do I use this information to actually authenticate against my rest backend? The rest backend actually contains the user data I need after all.
Originally, I thought I could just send my access token or id token to my backend and the backend uses this as proof that I'm the correct user.
Main problems I see:
Make sure the access token / id token is actually from my application (the SPA)
Be protected if the tokens are stolen / Minimize the impact of this
For the first problem, the client_id might help, which is embedded in the id-token. It is kind of public information (because it is an SPA) and there is no client_secret. But the redirect_uri is specific to my SPA. Is this enough protection?
If it is my backend could have a list of allowed client ids and providers and check if the client id of the token is one of them.
The second problem is the lifetime of the token. Access tokens are only valid for a short time period and refresh token should be rotated. So it's kind of okay to store these in local storage. But the id_token is valid for a longer time. What do to about this?
Is this in general the right track? Or is my approach completely wrong?
I'm looking for the best way to do my routing in my web Api.
Currently my routes are like these:
[Route("api/branch/{branchId}/products")]
[Route("api/branch/{branchId}/clients")]
In order to consume the api, I need to send a token with the authorization header. The token has the user branchId as a claim.
With my current setup I would need to give the user the branchId to the user in order to consume the api, I prefer not.
What would be the best way to implement the solution just by using the token with this route?
[Route("api/branch/products")]
I know that I would be able to extract the token values in every controller using the UserManager, but that would be to much repeating code
What would you suggest?
Thanks
Alberto Lopez
Write middleware to extract the claim value from the token and store it in the current http context.
HttpContext.Items["branchId"] = branchIdFromToken;
Then you can just use it anywhere where the request context is available by calling HttpContext.Items["branchId"].
A sample for writing middleware and extracting claims from the token (different purposes though) can be found here.
Problem statement:
Hi. I have some secured data which I want to expose through Web API and ASP.NET Identity mechanism. I want to use out of the box classes of ASP.NET Identity. I take a payment manually and change a value in the table. But there are cases where the user will share his username + password with some other guys so that the others can access the same content without paying anything.
Work plan:
So, I have extended the AspNetUsers table with a column named ApplicationToken (varchar). After successful login, I want to generate a token, update the field of the user's row in the table, and add this value as a claim information and send back to the client app. Now, when the user requests for a paid content, my client app will send the token also. So, somewhere in my server side codes, I need to check this ApplicationToken with the Database token value. If both are equal, I allow the request to proceed, otherwise I will send 401 Unauthorized and tell them to login again.
Implementation options:
After studying and searching, I found the below options to implement:
Create Custom Authentication Filter attribute so that I can grab the claims send from the client and do my required validation
Create a base class of the secured API and get the claims there and do my required validation.
Go for different Jwt based implementation where I should have access in both issuing and checking the Json Web Tokens.
If you have any other options, I would be very glad to hear those.
My question is, which approach is better to proceed. I have enough time to implement, so time is not a factor here. Thanks.
I have the ability to login via Facebook and Google on my website. This is done using OAuth2.
I use the same redirect URL whether the user is returning from facebook or google, and pass through the provider name in the state field. Is this the recommended way to track the provider? Otherwise I do not know who to validate the token with if I do not know which provider the token comes from.
Are there other preferred methods for accomplishing this?
The state parameter should be an opaque value that cannot be guessed by an attacker since it is not protected from modifications. If you need to track state, you should refer to it by using the state parameter but that parameter itself should be randomized and/or encrypted. Storing the provider identifier in plaintext in the state parameter is not safe. Users could modify the state parameter themselves or attackers could craft an authorization request with a state value that they choose.
The way to track the provider is by storing it in the backend session state and generate a reference to that session/state that you pass in the state parameter. To prevent cross-site request forgery you should also keep some encrypted/randomized cookie that binds the state to the browser. This is described in more detail: https://www.rfc-editor.org/rfc/rfc6749#section-10.12
Addendum:
One of the problems with using OAuth 2.0 + provider specific extensions for login is exactly this: you cannot establish the provider and user identity in a way that works for all providers in a uniform and generic way. In your case you'll already have to know the provider before you can perform a sensible interaction with it. Enter OpenID Connect: it is a extension profile of OAuth 2.0 that gives you login semantics in a standardized way. It would give you a verifiable JSON object (JWT) with standardized values that tell you who the provider is (iss) and who the user is (sub).
Google signin already has migrated already to OpenID Connect, as has Microsoft and others like Salesforce, hopefully Facebook will follow.
I'm implementing my own OAuth authentication system (with refresh_token support) for an app and I have some questions about how to do it:
Client identification: The client is registered in the auth server and gets a client_id and a client_secret. How do I generate it? is there some kind of relation between both values?.
User authentication: The client sends the users_credentials (username+password for example) + client_id and gets a refresh_token and (temp?)access_token. That access_token is the one I should use in further request or I should use a accesss_token`=F(refresh_token,access_token,client_secret). In the second case what does the F function consist on?
Access token refresh: The client send client_id, refresh_token and gets a access_token (and a optional new refresh_token). Does the access_token need the same conversion (whatever it be), as in the point 2?
If I'm wrong, when and how is the client_secret used?
Complete answers and concrete examples will be "bountied".
The authorisation/authentication server generates these values when you create an account with them (for instance when you create a developer account with Facebook or Google). If you are doing these parts yourself, they should be cryptographically secure pseudo-random numbers or letters. Remember that the client ID is usually publically visible, so choose a reasonably large set of alpha-numerics (I use 30 characters). The secret is private and can be harder to guess so I chose 30 digits with letters, numbers and symbols. These are not related to each other, it is just that one is public and the other isn't.
The usual way this works is that there is a browser redirect to the auth server passing the client id in the URL (and redirect uri) and specifically NOT the user id and password. The whole point of OAuth2 is that the client system never sees the user name and password, only the auth server. After this redirect, the auth server verifies the client id, checks the username/password (for instance) and then returns to the redirect uri with a temporary code. This temporary code is passed back to the Auth server in order to obtain an access token. Since this call is made as a POST from the server, it also passes the client secret to verify that it really is the correct client system and not someone who stole the client id from somewhere else. At this point, the auth server will return an access token (and optional refresh token - you do not need to use them, I don't).
If the client system wants to log the user in without them having to type in their username and password all the time, it can use a refresh token, if available, to call back onto the Auth server and if the Auth server is happy that the refresh token is still valid and any other business rules are correct, it can give you back another access token directly without the user being involved.
I recommend reading the OAuth2 spec here: OAuth2 Spec RFC6749. It can take a while but if you delete the bits you don't need and reduce the amount of data, there are plenty of useful examples in it.
FIRSTLY, The client identifier can be any string that you want, but it should be unique for each client. It can even be the client's choice if you wish.
The client secret should be a cryptographically strong random string. Here is how you could generate one in C#:
RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;
SECONDLY, The whole point of OAuth is to allow external apps to do things on your behalf without asking for your credentials. So, you need to implement an authentication server that does the logging in part for you. The user opens the app and gets an option to Log in using your website. You tend out access tokens and refresh tokens once the user has keyed in his credentials. The app can then simply use the tokens to perform actions on the user's behalf. I wrote an answer to How would an efficient OAuth2.0 server / provider work? that explains how access tokens can be constructed.
Remember, the need for refresh tokens and the lifetime of access tokens purely depends on how you intend to use them and what does your security framework look like.
LASTLY, The refresh token can also be an HMAC encoded string/a JSON object as I had explained in the answer to the linked question. You can have random refresh tokens and a large backend storage to keep it to verify the tokens in the incoming requests, or have HMAC encoded strings for added security/less storage requirements/latency to decrypt/encrypt tokens.
Also, do make sure that you go through all the flows and possibly the RFC too as mentioned by Lukos.