Thanks to this page api_key_authentication I have an authentication system which works well.
So, basically every user has his own api_key field (stored into the fos_user table), when I perform a request with any api_key from fos_user I see in the response that the user is recognized.
The question is: What does an API user do to retrieve his api_key?
You can generate api key and send it to the user (somehow) or make auth api where user send you his login and password and then you generate and send him his api key (this is the most known way).
Related
I am learning to connect to one of our 3rd party's API, and the first step in doing so is to first get an access token to use for additional requests.
To get that access token, I send a POST request that includes an API key in the header, along with the username and password in the body (as JSON). And that successfully returns a token.
But how do I set up that up in a collection? In postman I have options of API token, Basic Auth, Oath2, etc. But I do not see how you set up and include both the API key and user/password.
I've tried different scenario's of just the API Key and Oath2 with credentials, but unsure how you set it up to include both.
I am using .NET Core 3.1 in my Web API project. In that, I have used JWT authentication. Now I want to allow users to log in or register using their mobile number. So when the user enters the mobile number an OTP will be sent and after verifying the OTP, I want to issue JWT for the user. Now, I have the below queries regarding this:
If this flow is correct or something needs to be changed?
Where should I store the OTP sent to the user's mobile number? Should I create a separate table for storing OTP and mobile numbers or it should be managed on the front-end site where I am using ReactJs?
Note: I cannot change the authentication mechanism from JWT to any other as I already have dependencies over it.
So when the user enters the mobile number an OTP will be sent and
after verifying the OTP, I want to issue JWT for the user. Now, I have
the below queries regarding this:
If this flow is correct or something needs to be changed?
First, I think the workflow is correct.
Generally, when we using JWT authentication, the workflow as below:
Client sends a request (which contains the user information, such as: name and password) to server for token
Server receives the user information and checking for authorization. If validated success, server generates a JWT token.
Client receives the token and stores it somewhere locally.
Client sends the token in the future requests.
Server gets the token from request header, computes Hash again by using a) Header from token b) payload from token c) secret key which server already has.
If ("newly computed hash" = "hash came in token"), token is valid otherwise it is tempered or not valid
So, in your workflow, you are using Mobile number and the OTP to login, and validate the user. It also is correct.
Where should I store the OTP sent to the user's mobile number? Should I create a
separate table for storing OTP and mobile numbers or it should be
managed on the front-end site where I am using ReactJs?
For this issue, I think it depends on how you generate/send the OTP.
If the OTP is generated by yourself, you have to store the phone number and OTP in the database, because, after client send the phone number and OTP to the server side, you have to validate whether the user is valid or not.
If you are using some provider or package to generate the OTP, might be the OTP has an expired time property, you can also store them in the database. If the expired time very short, there is no need to store them in database, you could try to use session to store the OTP.
I have already implemented my own IPersistedGrantStore called PostgresPersistedGrantStore that stores grant in my postgresql database and it works really great.
Now i want to move really forward and i want to get the refresh token from the key that is stored in my postgresql table. But from what i read it is not a proper refreshtoken but a hash to protect the refreshtoken. Is there a way to decrypt, read the refresh token from the key property, using maybe a fuction from the identityserver api?
I am trying to implement my own impersonation workflow, so it would be easy to login as any user using the latest refresh token that exists persisted in my db
A long time has passed since the question had been asked, but I think I'm sharing a relevant information.
Here is the method which is implemented at IdentityServer4.Stores.DefaultGrantStore<T> and actually creates the key for the refresh token.
protected virtual string GetHashedKey(string value)
{
return (value + KeySeparator + GrantType).Sha256();
}
Where
value is the actual value of the refresh token,
KeySeparator is a
constant string field defined at the same class, the
value is ":",
GrantType is 'refresh_token' in this particular case.
This method is being used while creating/validating the refresh token.
I think this information clearly states that there is no way to get the refresh token value by using the key.
Reference:
https://github.com/IdentityServer/IdentityServer4/blob/main/src/IdentityServer4/src/Stores/Default/DefaultGrantStore.cs#L77
Identity Server 4 has a build-in endpoint for this - <server_url>/Connect/Token.
You need to send a POST request to this endpoint, with x-www-form-urlencoded body type, which contains:
refresh_token: current refresh_token
client_id: the client that you are refreshing the token for
client_secret: the secret of the client
grant_type: refresh_token
It will give you back a "refreshed" access_token along with a new refresh_token.
The initial refresh_token you should have received once you have logged in. Have in mind - once refresh_token is used (to get a new access_token) it gets invalidated. This is why you are receiving a new with every request to the endpoint.
Here is some more info about the refresh_token itself.
And here - about the token endpoint.
There is an app that wants to authenticate with my users using oAuth2.
So they open a window, with the authorize URL, and parameters (such as redirect uri)
Like: https://my-website.com/api/authLauncherauthorize?redirect=SOME_URI
Now I have my own firebase-login, and when the user logs in, I get their access token from firebase. Which is what I want to respond with.
However, in oAuth2 guides/explanations like https://aaronparecki.com/oauth-2-simplified/ I see I am supposed to return an authorization code, and I don't understand where can I get that from?
What I can do, is generate a bullshit code, pair it in the DB to the access token, and then in the "token" request, send the correct access token. Is that what I am supposed to do?
Just to be clear, this is my first time writing an oAuth2 service myself.
OAuth is a system that provides authenticated access to resources. This resource can be for example a user page or editing rights to that user page. So your goal is to provide access to permissions to the right people.
When someone logs in, they get a token. Your part is to generate that token however you want, may it be some form of userdata into base64 or completely random. Take this token and link it against permissions, like viewing a page, editing it or even simpler things like viewing the email of a user.
OAuth2 tokens and/or permissions should be revokable without deleting a user. You should not use OAuth2 to identify someone.
If I am understanding your question correctly:
User visits some website
User wants to register or login using your websites OAuth2
You redirect back to the original page and send your generated token
The page can access content on your site with this token
Assuming you are the Host Site, given a User who wants to connect a 3rd party application, then the flow would be like this:
User lands on site - Clicks Login with Github
User is redirected to Github site where they login and click "Authorize"
Github redirects user back to your site /authorize with an auth token.
Your site then passes that token back to the 3rd party API (github in this case) in exchange for an access token and refresh token.
You can then pass that Authorization token to an API endpoint to get details about it. If the token expires, you can use the refresh token to get a new Auth token. Both Tokens should be stored in your database for your user.
However writing that all out I realize you are asking how do you generate the Authorization token, so I'm guessing you're actually the 3rd party API in this example. So you would want to generate an Authorization token using a random generator. Since you are using firebase, you'll probably wanna try out their token generator: https://github.com/firebase/firebase-token-generator-node
There's also some more up-to-date info here I believe: https://firebase.google.com/docs/auth/admin/#create_a_custom_token
And like you said, you would store that in a database associated with the user, and then when the Host Site sends that user's auth token to your server, you exchange it for the Authorization token (and refresh token if requested).
It's also worth reading through how google does it, because you'd be doing something similar: https://developers.google.com/identity/protocols/OAuth2UserAgent#validatetoken
JWT is another option of generating tokens: https://jwt.io/
I want to enable Facebook authentication and the FB-Graph in my website, which already has forms authentication. Using http://multitiered.wordpress.com/2010/08/05/getting-started-with-the-facebook-c-sharp-sdk/, I was able to figure out how to login server-side.
However, the problem with this approach is that a secure cookie will not be created, since the call returns the authentication code in the querystring via a callback. This means that the user will have to login every time.
I can see two ways around this:
Store the access token in a secure cookie manually
Instead of the above approach, use the FB JS API to login - this stores a secure cookie with the access token automatically
I would prefer not to use the second approach, as I would like the login code to be server-side.
Which would be the better approach? Am I missing something?
I use the JavaScript method to first authenticate the user, the JS SDK then writes an encrypted cookie (called "fbs_[YourAppID]") when a connected user hits your page; using one of the many Facebook c# SDKs, this cookie can be decoded using your application secret giving you the user ID, oAuth token, expiry date etc.
Then I hook into the AuthenticateRequest event of my .NET application, check the presence of the cookie, decode if it found, and then find a user who has been assigned this facebook ID (your user table must have a extra field for storing the ID of their facebook account).
If a match is found, I write a normal forms authentication cookie for this user, then .NET will recognise them for all future requests. If no user is found, then this is a brand new user who has just connected. Use the SDK again to query the graph API using their oAuth token, get things like their name/email etc and create a new account, then issue a authentication token as normal.
By writing a normal authetication cookie, the user will stay logged into to your site for all requests, just as if they were a normal user.
One side point, when using email address, check for duplicates, and check for the facebook cookie in all requests. For example, an existing registered logged in user may have just connected.