I'm writing a web frontend in vapor which has a login and signup pages, and an authenticated user area with actions that require being logged in.
There is a seperate instance (also swift vapor) which handles authentication over a rest api (basically there are multiple other things which can authenticate, and from various sources/reasons so made sense to have it as a seperate instance).
The idea is all the authentication is passed on from the webserver to the api
The idea and what I have currently is the web's /login page has a form which sends a /login POST request which talks via the api instance sending a post request (/auth/login). This either succeeds or not. and the webserver responds based on the api response
The issue I have is how I persist that authentication- do I need some custom middleware to store the session token or check the token via the api that I can use on subsequent requests?
I've enabled bearer authentication on the api, and the api's success login reply json object returns the session token that I check in the bearer authorisation.
There's also a vapor-session set cookie returned in the api's login response. I've tried adding that into the web's login response (redirect response to the logged in area) so the browser should send back the session cookie on future requests but I haven't as of yet been able to get this to work. The browser is sending a different value for vapor-session cookie.
Does this sound like a sensible approach?
I'm not sure the best way of going about this
Including some bits of code to help see what I have so far
API instance's routes, I'm sure if I need the session authenticator or not
auth//.grouped(UserDB.sessionAuthenticator())
.grouped(UserAuthenticator())
.grouped(UserDB.guardMiddleware())
.group("")
{ authenticated in
authenticated.get("me", use: getCurrentUser)
This is the UserAuthenticator that supports bearer authentication by looking up the session token in the db. Could I just use the session token in bearer auth header for all requests web -> api? I'm not sure how I'd provide that on each web request- should I be setting a cookie? Is that basically what the vapor-session cookie is?
struct UserAuthenticator: BearerAuthenticator {
typealias User = UserDB
func authenticate(bearer: BearerAuthorization, for request: Request) -> EventLoopFuture<Void> {
let tokenHash = SHA256.hash(bearer.token)
return request.sessionTokens
.find(tokenHash: tokenHash)
.flatMap {
if let sessionToken = $0 {
request.auth.login(sessionToken.user)
}
return request.eventLoop.makeSucceededVoidFuture()
}
}
}
I haven't put any middleware on the authenticated web routes- should I be doing that and checking there? would I do an api request in the middleware authenticate method?
I'm not really sure what the correct approach is here
Assuming your front-end and API are separate you need a custom User type to add to the authenticated session - this is how you know a user is logged in. You probably don't need to store much on the user, just their username and the API token
I'm writing a dropbox integration against my own account. When file get dropped I respond to a webhook notification and import the files into one of our backend systems.
It's all done in back end server code and there is no real opportunity to pop up a UI to get me to sign in.
I've developed it so far using the access token you can get from the app console but that expires after a few hours.
Are there any auth shortcuts when using the API with just your own account?
I've figured out some shortcuts for myself
First off all as its a background process it needs to be running with "offline" access and using refresh tokens to acquire short lived access tokens.
As there is no UI and its only for my own account I can get an authorisation code via the browser from this URL
https://www.dropbox.com/oauth2/authorize?client_id={{Your APP ID Here}}&token_access_type=offline&response_type=code
then use POSTMAN to get an access Token & Refresh Token:
In Postman:
Post to https://api.dropboxapi.com/oauth2/token
Authorisation Basic
UserName = {{AppKey}}
Password = {{AppSecret}}
Body :x-ww-form-urlencoded
code = <<Auth Code From Browser>>
grant_type = authorization_code
This produces a result with an access_token and a refresh_token
The refresh token will only expire if I withdraw access so that will be safe to add into my config and use to request access tokens or connect to the client.
In my case its c#
using (var dbx = new DropboxClient(refreshToken,appKey,appSecret))
{
var myAccount = await dbx.Users.GetCurrentAccountAsync();
String.Format("{0} - {1}",
myAccount.Name.DisplayName,
myAccount.Email)
.Dump("Account Details");
}
At first, i expected access token to be necessary while communicating with WL resource.
Expected flow:
1. WLAuthorizationManager.login(this.securityCheck ,{'username':username, 'password':password, rememberMe: true}).then(
2. WLAuthorizationManager.obtainAccessToken(this.securityCheck).then(
3. let resourceRequest = new WLResourceRequest('someURL', WLResourceRequest.GET)
resourceRequest.addHeader("Authorization", "Bearer " + accessToken);
4.
resourceRequest.send().then(
where 1 = login, 2 = get access token, 3 = add access token to header, 4 = access resource
However, i find that without 2, 3, i can still access the resource.
It comes to my concern what is the meaning of obtainAccessToken and add Authorization header.
Is there any token auto bound to WLResourceRequest after login?
Is there other way to login without using WLAuthorizationManager.login?
If ok, how to let server know the user logged in like using WLAuthorizationManager.login?
If the above is true, after custom login, can obtain access token?
Here's some background about these methods and their working:
WLAuthorizatonManager.login(securityCheck, credentials) logs into a
specified security check. This method does not create an OAuth token.
More details about WLAuthorizatonManager.login(securityCheck, credentials).
WLAuthorizationManager.obtainAccessToken(scope) returns an OAuth token
containing the specified scope.If the scope is mapped to a security check, it will trigger a corresponding challenge, which the client will have to handle to obtain the token. If obtainAccessToken(scope) is invoke after a successful login(securitycheck) call and if the scope is mapped to the same securitycheck, then you will not see a challenge. The OAuth token will be granted.
More details about obtainAccessToken().
WLResourceRequest object is used to send a request to any protected or
unprotected resource using an absolute or relative URL.
WLResourceRequest object automatically handles the MobileFirst
OAuth-based security model protocol and invokes the required
challenges.
Details about WLResourceRequest.
To answer your questions:
Is there any token auto bound to WLResourceRequest after login?
As mentioned earlier, WLResourceRequest automatically negotiates an OAuth token from MFP server containing the scope that protects the endpoint it is accessing. This may include multiple rounds of OAuth negotiation and also invoke the challenge handlers to handle challenges originating from the server. Once the right token has been obtained, the API automatically adds the token to the request in an 'Authorization' header.
Is there other way to login without using WLAuthorizationManager.login?
Instead of WLAuthorizatonManager.login(securityCheck, credentials), if a protected resource is accessed via WLResourceRequest or if WLAuthorizationManager.obtainAccessToken(scope) is invoked for a scope that is mapped to a security check, this will trigger a challenge response cycle that will end with a user identity and a token.
If ok, how to let server know the user logged in like using WLAuthorizationManager.login(securityCheck, credentials)?
MFP runtime takes care of this - regardless of if the user identity is set via WLAuthorizatonManager.login() or if WLResourceRequest / WLAuthorizationManager.obtainAccessToken(scope) triggers a challenge response cycle that goes through the securitychecl.
If the above is true, after custom login, can obtain access token?
Not sure what you mean by 'custom login', but you can always obtain an OAuth token using WLAuthorizationManager.obtainAccessToken(scope) or WLResourceRequest. The difference is that obtainAccessToken() will get you a token for the scope you specify, while WLResourceRequest will invoke an endpoint by obtaining an OAuth token covering all the required scopes automatically.
In my REST API, user will log in with their username and password for the first time.
When they logged in successfully, we will response with the following format.
{
"token": "0c7f8b870675bc61d92baeef1e274c2d31343736393530373230",
"expire_on": "2016-11-19T18:05:20+0000",
"user_id": 30,
"user": {...}
}
On the subsequent to the REST API, we will just send token in the header to verify the user. token is 52 letters long.
Is it secure enough?
Should I send both token and user_id to verify to secure more?
It depends on how do you generate your token.
If someone can guess how they are generated then it can create a fake one.
If this is a random string that is saved on your server and for each request you check the existence in your server then you are safe.
The best current solution for stateless token is JWT. Take a look at https://jwt.io/
Did you implement your authentication layer? I would suggest having a look at the Oauth2 specification and you are interested in the section when the grant_type is password. If you follow it, it will be safe to return just the access token:
5.1. Successful Response
The authorization server issues an access token and optional
refresh token, and constructs the response by adding the following
parameters to the entity-body of the HTTP response with a 200 (OK)
status code:
access_token
REQUIRED. The access token issued by the authorization server.
token_type
REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive.
expires_in
RECOMMENDED. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
If omitted, the authorization server SHOULD provide the
expiration time via other means or document the default value
.
Why do you need both a "code" and a "token" in the Facebook OAuth2 authentication flow as described here: https://developers.facebook.com/docs/authentication/ ?
If you look at the OAuth dialog reference (https://developers.facebook.com/docs/reference/dialogs/oauth/), it seems like you only ever use the token to fetch information about the user, and if you specify the response_type parameter as token or code,token, then you get the token on the first time.
Why do you need to get a "code" and then use the code to get a "token" as opposed to getting the token directly?
I guess I'm misunderstanding something basic about how OAuth works, but it seems you avoid the request to https://graph.facebook.com/oauth/access_token entirely if you get the token the first time with the dialog.
Let us take a simple example to differentiate authentication code vs access token.
You as a user want to try a new Facebook app called Highjack.
So you click on the application and the Highjack app asks you to log into your Facebook account. When you are done, Facebook generates an authentication code for you.
This code is then passed to the Highjack server which uses its own FB client id, FB secret and your authentication code to get an access token.
In the above example the authentication code is confirming you as a user is a valid FB user. But the second steps says "you as a FB user is giving access to the Highjack app for certain resources".
If the Highjack app wanted implicit grant (i.e direct access token), then the access token would be visible to you also since it is being exchanged with the browser. This means you can now call all Facebook APIs on behalf of Highjack using the access token. (You can only use the access token to get your personal information but Facebook has no way of knowing who is calling their APIs.)
Since we have 2 parties (You and Highjack) authenticating with Facebook we have this 2 fold mechanism.
Borrowed shamelessly from Salesforce Documentation:
Authorization Code
An authorization code is a short-lived token representing the user's access grant, created by the authorization server and passed to the client application via the browser. The client application sends the authorization code to the authorization server to obtain an access token and, optionally, a refresh token.
Access Token
The access token is used by the client to make authenticated requests on behalf of the end user. It has a longer lifetime than the authorization code, typically on the order of minutes or hours. When the access token expires, attempts to use it will fail, and a new access token must be obtained via a refresh token.
From the OAuth 2.0 Spec:
The authorization code provides a few important security benefits
such as the ability to authenticate the client, and the transmission
of the access token directly to the client without passing it through
the resource owner's user-agent, potentially exposing it to others,
including the resource owner.
So, basically - the main reason is to limit the # of actors getting the access token.
"token" response is intended primarily for clients that live in the browser (e.g.: JavaScript client).
Answer) You need/want both the code and token for extra security.
According to Nate Barbettini we want the extra step of exchanging the authentication code for the access token, because the authentication code can be used in the front channel (less secure), and the access token can be used in the back channel (more secure).
Thus, the security benefit is that the access token isn't exposed to the browser, and thus cannot be intercepted/grabbed from a browser. We trust the web server more, which communicates via back channels. The access token, which is secret, can then remain on the web server, and not be exposed to the browser (i.e. front channels).
For more information, watch this fantastic video:
OAuth 2.0 and OpenID Connect (in plain English)
https://youtu.be/996OiexHze0?t=26m30s (Start 26 mins)
If you look at the flow of Authorization Code OAuth type, yes, there are actuary two steps:
<user_session_id, client_id> => authorization_code
<client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token
In step1: the user tells the OAuth Server that "I want to auth this client (client_id) to access my resource. Here is my authentication (user_session_id or what else)"
In step2: the client (client_id) tells the OAuth server that "I've got the user the authorization (authorization_code), please give me an access token for later access. And this is my authentication (client_id & client_secret)"
You see, if we omit step 2, then there is no guarantee for client authentication. Any client can invoke step1 with a different client_id and get an access token for that client_id instead of its own. That's why we need step2.
If you really want to combine step1 and step2, you can do something like this:
<client_id, redirect_uri, client_secret> => access_token, refresh_token
We use this approach in our Open API Platform, and we haven't find any security problem yet.
BTW, there is actually an Implicit Grant type, that is:
<client_id, redirect_uri> => access_token, refresh_token
It is generally applicable to client only application which have no server backend. In that case, the OAuth server must ensure that the redirect URI belongs to that client (same with the register redirect_uri, for example).
The mix-up came because the user on behalf of himself and not the client app authenticate against the authorization server (i.e. facebook).
Its much simple to secure the client app (with https) then the user-agent (browser).
Here is the original formulation from IETF-oauth (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4):
3.4. Authorization Code
An authorization code represents the intermediate result of a
successful end-user authorization process and is used by the client
to obtain access and refresh token. Authorization codes are sent to
the client's redirection URI instead of tokens for two purposes.
Browser-based flows expose protocol parameters to potential
attackers via URI query parameters (HTTP referrer), the browser
cache, or log file entries and could be replayed. In order to
reduce this threat, short-lived authorization codes are passed
instead of tokens and exchanged for tokens over a more secure
direct connection between client and authorization server.
It is much simpler to authenticate clients during the direct
request between client and authorization server than in the
context of the indirect authorization request. The latter would
require digital signatures.
Theoretically,
Access Tokens cannot tell us if the user has authenticated but auth code does.
Auth code should not be used to gain access to an API but access token should be.
If you have a single page application or mobile application with no or minimum backend, your application may want to access user's FB data directly at frontend. Hence the access token is provided.
In another case, you may want a user to register/login to your app using some external auth service provider like Facebook, Google etc. In this case, your frontend will send the auth code to the backend that can be used to get access token from Facebook at serverside. Now your server becomes enabled to access user's FB data from the server.
Basically, as an extension of Lix's answer, the access code route allows a Resource Owner (i.e. the Facebook User) to revoke authorization for their User Agent (i.e. their browser), e.g. by logging off, without revoking authorization for an offline Client (i.e. Your Application).
If this is not important, then there is no need to use the access code route.
Furthermore, the access code is provided to ensure that the Token provided to a server is actually registered to the Resource Owner (i.e. the Facebook User), and not the User Agent (or a Man-in-the-Middle).
This seems similar to the question of either choosing the implicit vs authorization code grant flow. In fact, here is what looks like an opposite view point?!.
Also, as Drew mentioned,
When the access token expires, attempts to use it will fail, and a new access token must be obtained via a refresh token.
another piece is the refresh token, but I don't see that being explained too well in the FB Docs. If I'm correct, the implicit grant (the direct token) should be really short lived, but that is to-be-enforced and FB.js seems to hide a lot of that (this one I have not looked as deep into).
If I'm correct, the code%20token is an optimization allowing both the User Agent to have a token and allowing for the server to initiate the token exchange process in a single request (as anything over Network IO is considered expensive, especially to a User Agent).
In OAuth 2.0 with facebook, the overall concept is simple as follows.
Step 1. Obtain "Authorization Code" by a GET request
request URI: https://www.facebook.com/dialog/oauth
Params:
response_type=code
client_id={add your "App id" got by registering app}
redirect_uri={add redirect uri defined at the registration of app}
scope={add the scope needed in your app}
Headers: None
Step 2. Obtain the "Access Token" by sending the authorization code as a POST request
URI: https://graph.facebook.com/oauth/access_token
Params:
grant_type=authorization_code
client_id=<add your "App id" got by registering app>
redirect_uri=<add redirect uri defined at the registration of app>
code=<obtained authorization code from previous step>
Headers:
Authorization:Basic encode <App Id:App Secret> with base64
Content-Type:application/json
Step 3. Use the access token got from above step and retrieve user resources
It’s because the access token is given to an AUTHENTICATED client (third-party app) using a shared secret that only FB and the client knows. The only way that the user could directly request the access token is by knowing the shared secret, which would make the secret public and could lead to a man-in-the-middle attack. Further, while FB can guarantee a secure connection to the user, FB can’t guarantee the handoff of the token to the client is secure. However, FB (and OAuth2) does require a secure connection between the client and FB. The access token is tied to the client public ID (usually hashed), which means only the original client application can use it to request the token because the secret is sent along with the authorization code to get the access token.
You recieve a token when the user logs in. But you might want to change the token when you are performing other actions. EG posting as your app/page or posting as a user with offline_access.