I'd like to know if each time my application runs I need to get the token and pass it to the server, or if it's only necessary once to register the application. Thanks a lot.
You need a token to register the GCM(push notification) to the Google Server. Then this token is passed and used in the server to send subsequent notification. This token should be persisted by the server so that it can be used to make API calls to the Google server. With this approach, your server and the Android device do not need to create a persistent connection and the responsibility of queuing and relaying messages is all handled by Google's servers.
For more information visit the Registering Client Apps and also check this documentation.
Related
I'm using an external service called auth0 in order to get an access token and let my users use my api. Auth0 is using Oauth2 protocol.
In short The user adds a username and a password, I'm doing a call to auth0 by using a client_id (apps have an id) and client_secret and I get an jwt access token in return. Then from there I carry this access token to have access to my own api since I can check its validity.
I have been looking around about how secure it is to store client_id and client_secret on the client side (e.g. web (javascript)/mobile (native or hybrid with ionic)) and everybody was saying that it's not secure since everybody can reverse engineer the code and get the client_id and client_secret. Ok...I can take it...what Can I do with them if I don't have credentials in order to get the access token?
Given that I don't want to store the client_id and the client_secret, one solutions I have thought is to make a direct call to my api (Java) with the credentials and then my api make a call to auth0 and return the corresponding access token. In this way the client_id and client_secret is stored in the backend and somebody cannot get them easily. Is that safe?
However I have some endpoints, e.g. creating use account, sending sms for phone validation etc, that cannot have credentials. How do I protect the api in such case? If I can't store my own access token on the client side how could I get an access token and access my own api without credentials?
Thanks
One possible solution that OAuth spec suggests is that you could have three different servers for your application.
client-side
backend server and an additional authentication server.
The preferred way of doing this would be that the client would send the user credentials to the authentication server. The authentication server would be a back-end server which contains the client secret
The authentication server will authenticate the credentials and return back the token.
The client will then use the token obtained from the authentication server to access the resource API server.
If you wanna know more check out this video
https://www.youtube.com/watch?v=rCkDE2me_qk
In my opinion you are almost certainly using the wrong OAuth flow. I use Auth0 with Ionic as both a web app and a native Cordova app. I don't have the client secret in my client code at all.
If you follow the Auth0 quickstarts (https://auth0.com/docs/quickstarts), you should be choosing (Native/Mobile App) if you are deploying to app stores, and (Single-Page App) if you are deploying the web version of Ionic. From there you can pick Cordova (for native) or Angular (for SPA). These should give you instructions that implement OAuth flows which DO NOT require your client secret. My guess would be you are referencing a "Regular Web App" quickstart, which runs server-side and CAN safely hold the client secret. That's not the world you're coding in if you are using Ionic Hybrid/Native.
I would consider wrapping the call to Auth0 into your own server side implementation as safe. Your API takes user credentials and then calls Auth0 and this way your client_id/secret are secure on your server and the client can be reverse-engineered all the way without compromising your security.
Regarding the other APIs which cannot have credentials you are pretty much out of luck. Their very use case is to be used by an unauthenticated third party, so at least the account creation API cannot really be protected. However you can still use some nicely designed constraints to limit the attack surface. E.g. you can require an email address/phone number to register and you will not allow the same address/phone number twice. If you set up your process that you first need to confirm your email address before you can validate your phone number this will make the life of an attacker a lot harder. He would need a real working email address, and some automation to receive your confirmation mails before he could get to call your SMS service. You could also rate-limit the service per IP-address so an attacker cannot cause your SMS cost to skyrocket by issuing a lot of calls for SMS validation in a short period of time.
I have a single player Unity game which records stats about game run-throughs, such as accuracy/runtime. I want these stats to be saved onto a web server / db so I can later aggregate them, the web server being a Node app using Express and the DB being a MongoDB instance. I have made the API routes to POST/GET the data but at the moment the routes are public. Normally, I would implement JWT whereby the user would have to login to be able to make web requests, but since the game is single player there is no login credentials to use.
What would be the best way to verify that a call to my web service has been made from within the Unity game without requiring the user to login/register an account?
So far I have thought about using a key on the Unity-side that needs to be sent through with each request, but this is prone to being discovered by searching through the source code.
Implement oAuth on top of your REST API on the Node side. Now a caller has to provide an access token when calling your API. Make sure your implementation supports a flow you're going to choose in step 2. oauth2authorize is a popular toolkit.
Choose an appropriate oAuth flow and implement it on the Unity side. One possibility is the client credentials grant, a flow designed for service-to-service calls. Another option is exchanging JWT for an access token; the payload of the JWT can reflect the security context of the caller being the Unity game itself.
I want to create a Twitter application which would use 'Sign in with Twitter' in order to get the users' access tokens. I then want to perform calls to the API on their behalf.
Should the API requests be sent from the client side, or from the server side?
Rate limits shouldn't make a difference because they are measured per user access token.
But I'm wondering if I'm forgetting other important factors because I'm very new to this.
If your client is a web browser, then the answer is no. Twitter API does not support CORS headers. Have the client connect to a server, and make your requests on the backend.
I am testing a server that uses google cloud messaging (GCM)
In order to perform the test without an actual device (for a faster way and actually test only the server side)
I am looking for a way to register as a client WITHOUT a device
I have from the server the project id and the sender id
But I see that I need an instanse id of the client in order to register to GCM (via https: //android.googleapis.com/gcm/send)
Is it possible to generate an instance id without an actual client?
P.S.
Maybe it will help I have found this code of Angular GCM client, and Python GCM client
but i couldn't succeeded to find a solution for registration yet
Thank you
I don't think you can remove the "client app" out of the equation as it is part of the architectural components of GCM:
A GCM implementation includes a Google connection server, an app
server in your environment that interacts with the connection server
via HTTP or XMPP protocol, and a client app.
However if you meant, without a real device, try using the emulator.
I have no interest in authenticating my clients as they are.
I do, however, want to make sure that anyone reaching my FireBase is authorized. Namely, that it's only via my Android app.
Could it be done somehow? I couldn't find any option or alternative in FireBase documentation.
The best approach I see is to have my app signed by a certificate, and aithorize itself using it.
To authenticate your app, use FCM (but regretably, it requires a server code):
Create an anonymous firebase account.
send an FCM message to your server, with the firebase account uid.
the server will create a node such as /uids/$uid/enabled.
have a rule to require it, e.g.:
".read" : "root.child('uids').child(auth.uid).child('enabled').val() == true"
The reason for the FCM message, is that in order to send such a message, the app should be "registered", which means the developer's signing certificate for the app is known. anyone attempting to send such an FCM message and not through your app will fail - even if someone re-sign (and probably modify) your app.
The drawback is, of course, you need your server to receive FCMs - which is very easy on the device, but harder on the server side.