Handling of 3rd party OAuth2 tokens

after some extensive research I still don’t know how to properly implement the following case. I think this question answers something similar, but I’m not 100% sure (Should client have access to 3rd party API access token?).

Let’s say I have my resource server (my-api.com), my identity provider and authorization server (my-idp.com) and have an client app (native or browser) (com.my-app).

The standard use-case is implemented with the authorization grant flow.

I now have a new use-case, where I need to request data from a 3rd party resource server (other-api.com). The 3rd party has an identity provider as well and offers OAuth 2.0 authorization and OpenID authentication flows. Resource owners of the 3rd party need to give their consent to my application so I can request their data and further use it in my application.

My questions are the following:

Is the on-behalf-flow what I need? It seems to be for two APIs which I control, not for 3rd party APIs.

How do I handle the 3rd party access, refresh and id token to make requests on-behalf of the resource owner?

  1. I could store the 3rd party tokens in my-api.com and append it to every request I do to request data for my user?
  2. I could store the 3rd party tokens in my-idp.com next to my user information?
  3. I could send the 3rd party tokens to com.my-app which would result in two tokens for each party. This seems to be awkward.

I would go for option 2 and would extend the functionality of my-idp.com. Is this a valid approach? My API my-api.com would then fetch the 3rd party tokens before it does requests on-behalf of my user.


Is this jwt access and refresh tokens logic/structure secure?

  1. User logs in
    1. User gets a refresh_token assigned and stored in the database (long lived 7d)
    2. Client receives an accestoken (Short lived, 2h), and stores it as a cookie. Client also receives the userId AES encrypted, and stores it as a cookie.
    3. As far as the access token is not expired, the user keeps using the token to navigate the website
    4. The token expires
    5. The expired access token gets send to a refresh endpoint, so is the userID (Aes encrypted) both currently stored in out cookies.
    6. The server decrypts the userId and retrieves the refreshtoken that corresponds to the user by selecting the refresh token from the database using out userId.
    7. Now we have in the server our refreshtoken and accestoken, so we refresh the token, and send back the new accesstoken. We also generate a new refreshtoken and overwrite our old refreshtoken in the database with the new one. (I guess I need to somehow blacklist my old refreshtoken at this point)

Reusing Bearer Tokens in Test System

We are integrating into a system and I have some concerns over the security. As a test, I have taken a bearer token that was issued in a request 2 months ago and managed to perform a successful, authenticated request to the test system.

The live system blocks requests using older tokens, which is good. However, it suggests that the live system has the potential to be either storing older tokens or the potential (with maybe an unintentional change) to accept older tokens.

I’m quite concerned that the test system would be developed in a way that allows reuse of tokens. Should this be a concern and what are the potential implications?

Thanks in advance

Storing third party API tokens in a database

This is my first question so if there are many mistakes with formatting or if there are any standards I should follow please let me know.

Currently I have a Node JS project that uses the Spotify API. The project displays the the users top played artists and tracks. I am following the Authorization Code Flow to obtain the access token. This access token will he used to query certain endpoints to obtain a JSON response of the data that will be used for my project. This token lasts an hour. I am currently storing this access token in a cookie and using this cookie to make new requests.

My question is is this acceptable from a security standpoints? This token does not have the ability to change any of the users profile settings or read sensitive data. However, if another person were able to obtain this token they could use this to see another users data. Or would it be more secure to store this access token in a database an query the database for access tokens whenever need?

Can Chrome Extensions steal OAuth tokens from redirect-uri?

This is a duplicate of a stack overflow question, since it might apply more to security and authentication best practices.

I’m working on auth between a Chrome Extension, Google Cloud Platform, and trying to send the id_token JWT to an AWS server to retrieve user data (and/or establish a session?).

My question is this — how can I prevent chrome extensions with tabs permissions from reading the GET request or the redirected URI which has the fully-validated user JWT?

The JWT confirms that a user is who they are, but how do I know my Chrome Extension is the one making the request to my backend?

I have a few ideas:

  1. Maybe I can make a private window that only my extension can control

  2. Maybe I can somehow use the nonce or get the nonce from my server first

  3. Maybe my chrome extension has a private key or some way to verify itself with my backend, which has the public key

Any help would be appreciated, it’s difficult to research this specific scenario.

var url = 'https://accounts.google.com/o/oauth2/v2/auth' +           '?client_id=' + encodeURIComponent(chrome.runtime.getManifest().oauth2.client_id) +           '&response_type=id_token' +           '&redirect_uri=' + encodeURIComponent(chrome.identity.getRedirectURL()) +           '&scope=' + encodeURIComponent(chrome.runtime.getManifest().oauth2.scopes.join(' ')) +           '&nonce=' + Math.floor(Math.random() * 10000000);  chrome.windows.create({ url: 'about:blank' }, function ({ tabs }) {     chrome.tabs.onUpdated.addListener(         function googleAuthorizationHook(tabId, changeInfo, tab) {             if (tab.id === tabs[0].id) {                 if (tab.title !== 'about:blank') {                     console.log(url);                     if (tab.title.startsWith(chrome.identity.getRedirectURL())) {                         const id_token = tab.title.split('#')[1];                         console.log(id_token);                     } else {                         console.error(tab.title)                     }                      chrome.tabs.onUpdated.removeListener(googleAuthorizationHook);                     chrome.tabs.remove(tab.id);                 }             }         }     );      chrome.tabs.update(tabs[0].id, { 'url': url }); }); 

is putting authentication tokens inside HTML body safe?

I have a project, a webapp/website that uses cookies to authenticate users with long randomly generated strings (also with samesite:lax, httponly, secure), however I also have an API which itself needs authentication tokens.

My current design is when the website server authenticates the user it generates the API authToken and injects along with the total initial state of the page and then the API requests are served with this authToken, is this flow inherently flawed? I thought of using an extra HTTP request after page loading to get the API authToken and thus avoid putting it inside the HTML body but that means more slowness since the page contents is usually dependent on the API requests which need an extra HTTP request after the page load to get the API authToken. I assume the connection is already over HTTPS of course.

Should a 2FA app require authentication to grant access to 2FA tokens?

I don’t know the theoretical background for 2FA so I’m asking here.

I’ve used a few 2FA apps before including Duo Mobile and Steam Mobile (Guard). When Duo is opened, it will display your tokens as you expect, but with Steam your Guard token is displayed wether you are logged in or not. The Guard behavior caught my attention because I was expecting to need to be logged in first to see the token, since the token is tied to my account unlike with Duo where services are registered for use. That being said, Duo could use a master password (a la LastPass) so further protect the tokens.

So my question is do the workings behind 2FA (mobile apps specifically) consider if a user should be authenticated on the 2FA app to get access to tokens?

My theory is the security level is the same as SMS 2FA, where you can assume only the real user can access tokens because they know the phone’s lock screen pin. In this system, the phone is the authenticator and exclusive access is granted by knowing the lock screen pin. But with 2FA apps, the app is the authenticator, but has no way to provide exclusive access. Anyone with access to the app (imagine a shared phone where 2+ people know the lock screen pin) can access the tokens.

Is this security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way to secure a REST API?

I’m trying to secure a REST API that I’m using as a backend for a single-page application. The API provides access to read/create/modify/delete protected resources, based on a set of permissions managed by an administrator. What I’m thinking is the following:

  • All connections must be over HTTPS; plain HTTP requests will be redirected to HTTPS.
  • Users have a username and password, which they create.
  • A client submits a username/password to a /login route; if it’s a valid password for that user, the server will return a short-lived access token and a long-lived refresh token.
    • The access token will be a signed JWT that identifies the user and has an expiration time.
    • The refresh token will be a GUID corresponding to a row in a database table; this row will store the user ID
  • When accessing protected routes (everything but /login), an access token will be required. The server will verify the signature, and if valid, will check the expiration time. If the token is not expired, the user ID will be made available to server-side code for authorization logic.
  • If the access token is expired, the client will automatically submit the refresh token to a /refresh endpoint for requesting a new access token. The server will check the database; if a corresponding row still exists, a new access token will be returned to the client.

Does this scheme sound secure?

Using OAuth2 with JWT, should a client pass along unused refresh tokens on a logout call?

I have a system with an OAuth2 authorization server. It hands out JWT access tokens and refresh tokens (the latter only to the mobile app client).

We don’t persist access tokens (as is normal with JWT) but we do persist the (hashed) refresh tokens together with some meta data to be able to revoke them so that users can log out other devices. We also only allow a single use for refresh tokens, the new request also gives back a new refresh token.

The OAuth2 login server itself uses regular basic auth with sessions. The user wants to be able to logout (single devices/clients) here. So of course I have to invalidate the session itself. But ideally I want to remove the refresh token that this client still has as well. The problem is that I don’t know that refresh token. A particular user could in theory have request multiple of them with their code request. The refresh token is also not normally passed in requests (only the access token)

Should I ask the clients (which are currently all under our own development) to send along their unused refresh tokens? Even if they ‘forget’ their refresh tokens locally, it still seems better if I also delete them on the server so they don’t linger around until their expiry time. Note I do know all the refresh tokens currently in use for a certain account but I don’t want to just delete them all because that would mean all devices are logged out. We also save some user agent-like info with the refresh tokens so users can use that to manually logout other devices, but it seems like a bad idea to try to perform string matching on those to automate that process.

Spending Tokens of Friendship in Starter Adventure

I have bought the Tails of Equestria starter set to play with my children. On page 5 of A Dragon’s Bounty the following things are stated:

  • Each pony begins with 1 Friendship point
  • You can spend 1, 2, or 3 friendship points for different effects

This begs 2 questions:

  • How do ponies get more than 1 friendship point?
  • What does spending mean? Do they just leave the game, or do you give them to another pony?

I wonder if this is explained in the full rules, which I don’t have.

Note: for people who only have the full rules, I should say that A Dragon’s Bounty is a GM-less, choose-your-own-adventure style affair.