I want to send emails with java and smtp using OAuth2 access_token
I am able to do it if I use OAuth2 type that prompts the user with a browser to allow access.
Now I want to use a google service account and send a jwt json file to get the access token
As documented here
https://developers.google.com/identity/protocols/oauth2/service-account
I get a response back from the token url (https://oauth2.googleapis.com/token) that has a access_token, but it does not return a scope attribute and also has a ton of trailing periods
When I use it to call the smtp it responds with a 400 error
My Question is does gmail api work with jwt tokens?
Do I need to also have a Google Workspace Account or can I just use a normal Gmail Account?
EDIT FOLLOW UP:
I called the token validator url and got this back
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=xxx
validateAccessToken response: {
"issued_to": "xxx",
"audience": "xxx",
"scope": "https://mail.google.com/",
"expires_in": 3599,
"access_type": "online"
}
Not sure if it is the issue but access_type = "online" instead of offline like when I do it with 3 leg auth that requires user approval for access. Doing the JWT way I do not see anywhere to define access_type when requesting token
Related
I am currently using a client-side React component to have a user login to Facebook via OAuth in my application. On the server-side, I use the npm package passport-facebook-token to validate the authenticity of the accessToken after a successful client-side login.
One practice I do not see often is in addition to asking Facebook if the accessToken is valid, shouldn't the server also check if the email provided by the client's payload matches the e-mail coming back from Facebook? Allow me to use defined client/server technologies to illustrate my question:
1) User uses React component on the client to authenticate with Facebook.
2) React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
3) The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token.
4) Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
My question is, should Node.js take the email that's also coming back from Facebook's access token verification payload, and verify that it is what came back from the React client? Would this not prevent someone from brute-forcing an accessToken and require them to not only have an accessToken but also know who the accessToken belongs to? This could prevent a user from submitting a bunch of HTTP POST requests to the Node.js server attempting different access tokens. They would not only have to guess an access token assigned to the application's clientID, but also know the e-mail it belongs to. Is this an over-engineered approach?
Really the best way I can think of to make your OAuth accessToken and 'code' value less prone to brute-forcing is using a Cryptographic Number Generator to create a 128-bit length string of random data and encoding it with base 64 to use as your code. It's extremely unlikely that it would be guessed by a computer or by someone redirecting to and from the authorization endpoint and the redirect-uri with query parameters.
Another method of fortification is limiting the rate of authorizations by IP address (which you can do instead of email through Node.js) but that is usually not a problem for most well-equipped hackers. I highly advise the first method for creating a more secure service.
Your approach to validate the email as well as the token is a bit superfluous because Facebook's opaque user access tokens are inherently tied to email.
From Facebook
An access token is an opaque string that identifies a user, app, or Page
"opaque" is defined by Auth0 here
Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage
In your case, the identifier is the user's email, and the server belongs to Facebook.
I will elaborate further. Here is your step by step with some edits:
User uses React component on the client to authenticate with Facebook, inputting both their email and password directly to Facebook. React component gets the token from Facebook on login success.
React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token because the access token is already tied to the email.
Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
This is Facebook's bug bounty program. If their OAuth was really as cracked as to require a second email validation, it would have been patched almost immediately by this incentive.
I'm in the process of migrating our software, which makes requests on behalf of merchants to PayPal using the PayPal SOAP API, to the PayPal REST API infrastructure.
I'm using the Client ID / Secret of my PayPal developer account to get a Bearer token from the Sandbox, using https://api.sandbox.paypal.com/v1/oauth2/token.
Then I'm doing a call to https://api.sandbox.paypal.com/v2/checkout/orders, using our the bearer token just got, to make requests on behalf of a merchant. I'm using the PayPal-Auth-Assertion header with the following (encoded) JWT-Token:
Header:
{
"typ": "JWT",
"alg": "HS256"
}
Body: {
"email": "[merchant e-mail]",
"iss": "[my client id]"
}
The "merchant e-mail" is one of the sandbox accounts I opened in https://developer.paypal.com/developer/accounts/
In return I get a (400) Bad Request {"error":"invalid_request","error_description":"No permissions to set target_client_id"}.
It seems like there must be an additional step for the sandbox account to grant permissions to the developer account. For the SOAP API, I could add the user name of a 3rd party in the following screen . Then I could use the same username as header value for X-PAYPAL-SECURITY-USERID. However, I cannot seem to link the sandbox account in the same way, because there is no "third party username" for the main account (the one I'm getting the Client ID from).
What exactly has to be configured to allow these types of 3rd party calls for REST API?
I'm using the PayPal-Auth-Assertion header with the following (encoded) JWT-Token:
You need to be a PayPal partner to be using that type of functionality. Contact PayPal if you want to be a partner.
If you want to use their generally-accessible APIs, you have two options.
Have every merchant create their own REST API App via https://www.paypal.com/signin?intent=developer&returnUri=https%3A%2F%2Fdeveloper.paypal.com%2Fdeveloper%2Fapplications , and copy paste their live client ID and secret into your configuration. This is the best solution, and it is the solution you should pursue.
Use the payee object: https://developer.paypal.com/docs/checkout/integration-features/custom-payee/ , which gives you less control (cannot capture authorizations or issue refunds, for example)
I'm creating an app in which you are supposed to signup/login to use it. Now I'm implementing a restful webservice for it and I'm not sure whether I'm going the right way. My workflow is:
To signup, the user types in his credentials like username, email and password. The app hashes the password and sends a post request containing the credentials as json to my webservice and the webservice saves the new user to the database.
To login into the system, the app sends a get request including the parameters username and hash of the password to the webservice, compares the hash values and returns an appropriate response code for success oder fail.
The communication between app and webservice is secured by ssl.
Is this the right and secure workflow of a signup/login system? If not, why is it not secure and can you recommend another workflow? Cheers.
The most important part should be that your web service is only reachable via https.
I assume you are talking about a mobile app.
The app should not hash the password, the web service should do it and then store the user.
Mobile apps can be reverse engineered and then you know how to hash your passwords.
So to create a user in a restful way would be to send a POST request with username, email and password in the body.
For example POST /users
{
"username": "john-doe",
"email": "mail#example.org",
"password": "some password"
}
For authentication/authorization you might consider OAuth 2 but that takes a huge amount of time to implement.
Another option would be to have another REST resource called access-tokens.
So whenever you need to authenticate you do a POST /access-tokens request to create an access token.
POST /access-tokens
{
"username": "john-doe",
"password": "some password"
}
Response
{
"access_token": "9d91c97fc0f98a6311f101246e252ab3230c261c2af",
"expries_in": 3600
}
Then the mobile app needs to take care of that it will always create a new access token shortly before it expires. OAuth 2 has also refresh tokens for this purpose which are delivered together with the access token. Then you can retrieve a new access token just by sending the refresh token to the web service.
Once authenticated you need to include the access token in the Authorization header in every request to the web service that needs authentication.
I want to create an app that will authenticate with my server using oauth.
My question is how will this work?
My client side will communicate using HTTPS with Facebook and get an Access Token. Then it should send it to my server side to authenticate? My server should save the token in the db? How it can validate the token?
how will this work. ?
When the client needs authorization to access some information about the user, the browser (user agent) redirects the resource owner to the OAuth authorization server. There, the user is faced with an authentication dialog (this dialog is not shown if the user is already authenticated), after which he or she is presented an authorization dialog explaining the permissions that the client is requesting, the information that it needs to access or the actions that it needs to do on his or her behalf.
Access Token should send it to my server side to authenticate? or server should save the token in the db?
From what you describe I'd suggest to use a server-side login flow.
-so that the token is already on your server, and doesn't need to be passed from the client. If you're using non-encrypted connections, this could be a security risk.
(after a user successfully signs in, send the user's ID token to your server using HTTPS. Then, on the server, verify the integrity of the ID token and retrieve the user's ID from the sub claim of the ID token. You can use user IDs transmitted in this way to safely identity the currently signed-in user on the backend.)
-See
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2#login
How to validate token ?
you can follow this link , you will get your step by step solution for an app.
Facebook access token server-side validation for iPhone app
on the client side I am using the flash API to sign in and auth the client
Facebook.init(MyFaceBooyKey, faceBookInit);
Then face book sends back to the client a Signed Request and other stuff.
I the client then sends this signed request to my server.
On my server I process the Signed Request and out pops a FaceBook User id (UID)
So now I am assuming that:
The client who sent the valid signed request is the owner of the Face book UID contained inside it, the client must know the password for that UID, and they are loged into facebook ?
Is this system safe ?
how can i safely use user client side facebook auth to then autho in to a second server, eg a sepreak facebook game server.
How can I make suer that the signed reques has not been coped in transit on the web,
and then sent to me by a thirs party, who now logs on to my server under a Uiffrent UID
How to all theas flash based facebook games auth the users ?
also I note that the same book auth vias the Desktop application dose not send a signed reques ? so how to do the auth to my server in this case ?
All of the auth flows with facebook use SLL (https) and so the data you send/get is secured.
The same goes for all of the graph api requests, if you try to make an api request in http while including an access token you'll get this response:
{
"error": {
"message": "You must use https:// when passing an access token",
"type": "OAuthException",
"code": 1
}
}
If you send the signed request and/or the access token to your server then you should do it by https as well and that way that communication will also be secured.
The client (and I assume you meany the flash client) is not the "owner" of the access token/signed request, your app is the "owner".
If you need the access token on the server side I suggest that you use the Server-Side Auth flow to get it.
If you then need the access token on the client side then you can use a client side auth, since the user already authorized the app and authenticated for sure (through the server side flow) the client side process should be completely invisible for the user, and at the end of it you'll have an access token on the client side as well (a different one than on the server).
"message": "You must use https:// when passing an access token",
"type": "OAuthException",
"code": 1
}
} "message": "You must use https:// when passing an access token",
"type": "OAuthException",
"code": 1
}
} "message": "You must use https:// when passing an access token",
"type": "OAuthException",
"code": 1
}
}