I'm trying server side to invalidate a registration token forcing the client app to request a new token.
Reading the docs:
The InstanceID is long lived, but may expire for the following reasons:
Device factory reset.
User uninstalls the app.
User performs “Clear Data” in the app.
Device unused for an extended period (device and region determines the timespan).
Instance ID service detects abuse or errors and resets the InstanceID.
Server-side code if your client app requires that functionality.
https://developers.google.com/instance-id/reference/
Whats the server side code that allows me to invalidate or force the expiration of the token ?
Thanks.
For example, using the google API:
https://iid.googleapis.com/iid/info/token?details=true
When doing a 'get' over that endpoint I get information of the token. When was created, in what platform is running, and what are the topics registered for that token.
I would like through the API make that token invalid.
Is this possible ?
Related
I'm trying to verify Firebase App Check tokens on my custom backend. Everything is fine so far, but there's one thing I'm not sure about: My backend is hosted on a private network therefore I need to know if grabbing key sets from https://firebaseappcheck.googleapis.com/v1/jwks is the only necessary outgoing HTTP request involved in the verification process.
The answer is "Yes" according to https://github.com/firebase/firebase-admin-node/issues/2014#issuecomment-1353472578
Obtaining the Firebase App Check public JSON Web Key Set is the only outgoing request for the app check verify token API. The SDK might make other http calls during the initialization based on your environment (obtaining the service account or credentials etc.) or if you use other APIs in combination with the App check token verification.
The rest of the JWT verification happens all offline. We also cache the public keys (JWKS) for up to 6 hours, so if your environment doesn't lose its state then the outgoing request to fetch the keys should not happen (if the keys are cached) every time you call the API.
I have migrated data from an app to another on Cloud Firestore, but the new deployment on the new app can't access the data on it.
I checked the config object and all the properties refer to the new app on Firebase.
Is the missing thing a kind of a link/glue between the running web app and Firestore?
According to the ErrorCode list (HTTP error code = 404), the App instance was unregistered from FCM. This usually means that the token used is no longer valid and a new one must be used.
This error can be caused by missing registration tokens, or unregistered tokens.
Missing Registration: If the message's target is a token value, check that the request contains a registration token.
Not registered: An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with FCM.
If the client app is automatically unregistered, which can happen if the user uninstalls the application. For example, on iOS, if the APNS Feedback Service reported the APNS token as invalid.
If the registration token expires (for example, Google might decide to refresh registration tokens, or the APNS token has expired for iOS devices).
If the client app is updated but the new version is not configured to receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
I'm reading through FCM token management best practices in the documentation (https://firebase.google.com/docs/cloud-messaging/manage-tokens) and have the following questions.
On initial startup of your app, the FCM SDK generates a registration
token for the client app instance... your app should retrieve this
token at initial startup and save it to your app server alongside a
timestamp.
Is the recommendation here to handle the token on app launch or just the first time the app is launched on install? Because I can't imagine given how many server interactions there are in the typical life of a client process that we wouldn't just update the token every time the app is launched and call it a day instead of creating additional tasks to keep these tokens fresh.
We recommend that you periodically retrieve and update all registration tokens on your server.
Is the recommendation here to null stale tokens?
We recommend that you periodically retrieve and update all registration tokens on your server. This requires you to add server logic to update the token’s timestamp at regular intervals, regardless of whether or not the token has changed.
I don't understand what this means. Is the recommendation here to task the server with updating a token's timestamp? What does this accomplish? And is the server capable of generating a token for a client?
According to the docs, as I understand, you have to :
On client side :
Store the token on your server on first launch (your server will consider that your token is valid for 2 months)
Update your token on server if it changes
On server side:
When a new token is registered store the token in your database and set his validity for 2 months (if the token already exist in your database then just reset his validity for 2 months again)
When a notification send fails, then remove the invalid token from tour database
Periodically (monthly suggested), validate all tokens and reset their validity date if valid (delete if not).
The token is generated only when you first launch the app after install, and in some reset events. So your token will stay mostly the same, it won't change in every app launch. The timestamp is what the server will check. Maybe this will help:
First Launch
Token generated, send to the server with timestamp
Regular Launch
Token retrieved(same token), send again to the server periodically (2 Months?)
Now, this is where it gets hazy. As far as I understand, the server should signal the app in some way to get the token again (even if it is unchanged) to refresh the token in the server database and then refresh the timestamp.
If a user authenticates via OpenID Connect on a client and triggers a long-running server-side request, how can the server keep the access token valid if the operation takes longer than the access token's expiration time?
We have an application suite consisting of several server-side backend applications (typically accessed via REST, HTTP, and/or WebDAV), several web frontend applications and several client-side (i.e. desktop) applications. We already support the Basic and Kerberos/Negotiate authentication schemes and are currently adding support for OpenID Connect.
Our backend applications are typically accessed by the web frontend and client applications, other server-side backend applications, and 3rd party customer applications when our software is integrated into their system. We currently pass OpenID access tokens via the Bearer scheme to the backend applications.
In a typical scenario, a user (authenticated on a local client or in a web frontend) triggers a server-side operation which may possibly run for several minutes, hours, days, or even weeks. This operation accesses other backends on the user's behalf, e.g. a Web-DAV based server-side file system, to access additional data. All backend applications need the user's authentication information to grant access and access further user details for authorisation (e.g. to only grant access to the user's own files).
Obviously, this means that the access token provided with the original backend call may expire before the operation is completed. The server therefore needs a way to refresh the access token without user interaction. Our code can already do this if it knows the user's refresh token (using the refresh token and the application's client ID and secret to access the OIDC Token endpoint).
But how can we "correctly" pass the refresh token to the server?
The client has (potentially) the full set of ID, access, and refresh tokens. But from what I understand, the Bearer scheme expects that the passed token is the access token. Compatibility is important here, since our backend applications may also be accessed by 3rd party client applications. Assuming that getting the refresh token into the server application is the correct approach at all, we therefore still have to support situations where the caller can only provide an access token (with the obvious implications that in these cases, long-running operations will not be able to access other backend services on the user's behalf).
I could imagine the server accepting either an access token or a refresh token via Bearer. But from what I understand, the only "argument" a client may pass with a correct Bearer authentication header is a single Base64 encoded string, i.e. the (access) token. The client could pass an access or refresh token here, but I don't see how the server could then tell which it is, as to my knowledge both token types are opaque.
I understand that the original idea is for server operations to be short lived, so that keeping the access token up to date is the client's responsibility. But surely we cannot be the first who do need to combine OIDC with long-running server-side operations. Is there an accepted way to pass a refresh token to a server, or, alternatively, a completely different approach that I'm missing?
Like the Facebook application, you only enter your credentials when you open the application for the first time. After that, you're automatically signed in every time you open the app. How does one accomplish this?
There's a commom line in all auto-login implementations
Upon an initial login, a token is received and stored on the client side
Upon subsequent visits, if token is available on the client side, the server resolves the identity and logs in automatically
Now concrete implementation variations can be numerous. The token can be a session ID (encripted or not), OAuth token, custom token, username and password should be avoided. Storing token can be on within a browser cookie, browser local storage, can have a server counter-part. Security is the major concern. Generally about the topic you can read more here https://softwareengineering.stackexchange.com/questions/200511/how-to-securely-implement-auto-login
You have an interesting explanation of how does Stackoverflow do it https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work.