In my app, after a user sends a message to someone, another function is triggered to notify the receiver. For that, the sender has to have the receiver's push token (front end). My question is: Is that safe? Is there a better approach?
I'm using Firebase but I couldn't figure out a way to send this notification through Google Cloud Functions...
Yes you can treat it as sensitive information. Tokens could contain information that when a malicious user accessed, it can be used to impersonate your app and send their own messages to users. While there's no reported instance (yet), it would be wise to follow the best security practices.
According to this documentation on Sending Notifications with Expo's Push API
We offer the use of an access token alongside the push token as an additional layer of security.
If you're using the expo-server-sdk-node, upgrade to at least v3.6.0 and pass your accessToken as an option in the constructor. Otherwise, pass in the header 'Authorization': 'Bearer ${accessToken}' with any requests to our push API.
Any requests sent without a valid access token after you enable push security will result in an error with code: UNAUTHORIZED.
You can check this blog on Implementing Push Notifications with Expo and Firebase Cloud Functions on how to push notifications securely.
Related
I am calling the app script execution API from my web app. I am getting ScriptApp.getOauthToken() and storing it inside sheet. When I open my web app I will get the stored access token and calling the execution API with the help of it.
But the problem is, after some time the token is getting expired and it is saying
authorization is required
when I call execution API.
Is there any way to keep access token alive or refreshing it whenever is needed?
I. You cannot and you should not. At least not natively
There is no native Google Apps Script service method for obtaining and exchanging a refresh token (and you would need one if you want to refresh an expired OAuth 2.0 token) for a bearer token. That said, there is no practical reason in storing the short-lived token obtained via getOauthToken method - if a user authorized your application, you can request a token on the fly each time you need to make a request.
II. If you still want to, use a library
There is an officially endorsed library for Google Apps Script that manages OAuth 2.0 flow for you. When using it, you can obtain a refresh token if you set the offline access to true when issuing the token.
III. If you really want to DIY, you can always make your own flow
It is possible to perform a complete Oauth 2.0 flow (both with and without user interaction) by using only the native tools by building a custom JWT token and exchanging it with Google Identity Platform endpoints. But that means you will have to manage everything:
Build JWT custom token headers and payload, then base64 urlencode them and sign with an appropriate signature and concatenate into a token.
Exchange the custom JWT for a short-lived bearer token, validate it and extract expiration time, then persist the token.
Each time you get the token from storage, check for the expiration time, and reissue the token again using the procedure in point 1 - 2.
Handle token revocation (note that you will not be able to invalidate it from Google's servers, only in your application).
And many more caveats along the way.
Note that the token cannot be "kept alive", it goes against the idea behind the OAuth protocol - the lesser the lifespan of an individual token, the better the security of your application.
I was looking into implementation of Exchange/O365 mail notification service using the exchange push notifications. To subscribe to notifications one has to use the subscribe web service/REST API with a call back URL. Upon successful subscription Exchange will call the URL with notification events for the user.
Suppose the call back URL will be hosted as a Web service in our environment (cloud), it has to be publicly accessible. That raises security concerns. I browsed through MSDN and couldn't find any way to secure this (security key/tokens/auth)call back notification event.
I want to know what are the options available to make this notifications in secure way OR is the push notifications approach not recommended at all in such scenarios. Streaming notifications approach is not possible because it requires admin credentials and and the third party client who would like to use email notifications via our service will reject such an option.
Do let me know if any clarifications is required.
Thanks in Advance!
I am working through some architecture issues in my head related to JWT authentication security and I'm trying to figure out the following:
How does JWT securely pass a secret between server and client?
Take a look at the below excerpt from from https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ ....................
CSRF can be prevented by using synchronized token patterns. This sounds complicated, but all modern web frameworks have support for this.
For example, AngularJS has a solution to validate that the cookie is accessible by only your domain. Straight from AngularJS docs:
'When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain can read the cookie, your server can be assured that the XHR came from JavaScript running on your domain.
You can make this CSRF protection stateless by including a xsrfToken JWT claim:'
{
"iss": "http://galaxies.com",
"exp": 1300819380,
"scopes": ["explorer", "solar-harvester", "seller"],
"sub": "tom#andromeda.com",
"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}
How does the client create and send a valid request including the xsrfToken claim unless it can first sign the JWT after including the claim? (This xsrfToken after all is what's supposed to keep EvilBob from forging a request right?)
More details regarding my current understanding of the JWT XSRF process can be found here http://spring.io/blog/2013/08/21/spring-security-3-2-0-rc1-highlights-csrf-protection/.
I can explain how Stormpath does it, there are some other ways as well. Stormpath includes a 'kid' (key id) field in the JWT header, which is the identifier for the API Key ID / Secret pair. The JWT was signed with the Secret, and the ID is stored in key id field. When Stormpath validates the token, it can retrieve the secret. This works across servers and services but is never passed to the client. Using the client to glue separate services together with the secret is extremely insecure.
The client SHOULD NOT generate the JWT, this needs to be done on the server. The server knows the XSRF token and can sign it in the JWT and put it in the cookie.
Hope this information helps!
The article appears to call this the "synchronized token pattern", however the solution described better fits with the Double Submit Cookies method rather than the Synchronizer Token Pattern.
Double submit cookies involves sending the cookie value in a header or body as well as sending it with the browser cookies that are automatically sent. If you are not supporting CORS, then setting a token in a header is secure anyway, as is with any custom header value (e.g. X-Requested-With). This is because a custom header cannot be sent cross-domain in the first place, so verifying that it has transported from the client verifies that it is not from another domain already. As a defence in depth strategy, you can set it to a random value, as explained by this answer.
The random value doesn't need to come from the server, nor be signed. It just needs to be generated by a CSPRNG. If generated client-side, window.crypto should be used for this. All the server does is check that the header and cookie values match.
A third party domain cannot forge a request because even though the cookie value will be sent by the browser automatically from the victim's machine, the attacker cannot include the value in the header or the request body.
With the Synchronizer Token Pattern the CSRF token is generated server-side and stored against the session. This value has to be sent from each form submission and is verified server-side that it matches the stored token.
I am trying to develop a chrome extension in which I need to use 3rd party Oauth2 authentication. The third party service I want to use, only supports POST requests. But it seems that the launchWebAuthFlow method in the Chrome Identity API, only supports sending GET requests, as all the query parameters are sent in the URL itself. Is this correct? If yes, how should I do authentication?
UPDATE : The API I want to connect is that of Pocket
Partially you're right about POST requirements. But it is only used to initialize Oauth flow.
According to the documentation:
1) You must make a POST request to obtain a request token from Pocket auth service
2) Redirect user to the auth page: https://getpocket.com/auth/authorize?request_token=YOUR_REQUEST_TOKEN&redirect_uri=YOUR_REDIRECT_URI
Which means that you have to make a simple XHR to retrieve request token and then you can use chrome.identity.launchWebAuthFlow function to begin Oauth flow.
Did you try launchWebAuthFlow? You may find that it works. Once authenticated, you can exercise the API via POST, using XMLHttpRequest. (launchWebAuthFlow only handles the authentication, not the API itself.)
I've wrote a tiny script that retrieves publicly available data from some APIs, in JSON format. I'm now trying to get some protected data out from bit.ly (click stats from a given user) and so I obviously need to authenticate via OAuth.
I don't seem to understand the role of client id and secret, as well as the user API key. I also don't get how to grab an access token (maybe generated during OAuth authentication?) to authenticate my HTTP requests of protected data. Do you guys know any good (e)book, article or any other resources I should read to understand in detail these architectural nuances of authenticated data retrievals and HTTP requests?
It is exactly as you suspect. The access token is granted during the OAuth process, which is basically a three step rocket of getting
Temporary credentials for your application
An end user needs to authenticate those temporary credentials, which grants you a verifier token
And finally you exchange your temporary credentials and the user verification for an access token.
Depending on which language/framework you are using, there are often good libaries available to help you implement an OAuth client. Check out: http://oauth.net/code/
But you will be well served by a clear understanding of how the whole thing works. Twitter has a great tutorial about OAuth 1: https://dev.twitter.com/docs/auth/oauth.
Regarding OAuth 2. Check out http://hueniverse.com/2010/05/introducing-oauth-2-0/. Hueniverse is a good resource for all things OAuth by the way.