Facebook API Question posted in
The official documentation for the Facebook APIs can be found here.

Facebook api – Limiting the scopes of an OAuth 2.0 flow

I want to set up a OAuth 2.0 flow in my code.

I want my code, to be limited to specific scopes (even if someone accidentally writes some extra code to request additional ones).

Let’s assume I want my code to be able to only access photos in facebook.

Is the only place to restrict the scope during the request to the authorisation server, e.g.

https://facebook.com/dialog/oauth?response_type=code&client_id=CLIENT_ID
  &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx

Or is there a way to enforce this restriction when issuing client_id and client_secret so that the following request will eventually fail?

https://facebook.com/dialog/oauth?response_type=code&client_id=CLIENT_ID
  &redirect_uri=REDIRECT_URI&scope=email,posts&state=1234zyx

My use case is for google APIs btw.

Tags:

2

Answers


  1. 0

    Not enough details provided to know what you are trying to accomplish; But generally:

    • The OAuth client may request any scope desired.
    • The resource owner
      (Could be end user "consent screen" or Google if using APIs) may NOT delegate some or all requested scopes.
    • The Authorization Server may ignore some or all
      requested scopes for many reasons.
    Login or Signup to reply.
  2. 0

    When first implementing an OAuth flow in GCP, I conflated GCP authorization with Google API authorization, and the mechanisms used to orchestrate them.

    First off, let’s define Authentication and Authentication:

    • Authentication is process of validating that an incoming calling Identity is who they say they are.
    • Authorization is the process of granting an Identity access to a system or parts of a system.

    Authentication

    GCP offers a variety of authentication flows, which are found in the IAM console. In your example, you may be looking at using:

    • OAuth 2.0 Client authentication with Client ID and Secret (this uses a standard Google User account, and Google provides the User account with credentials)
    • Service Account authentication with a Service Account "Key" (this method creates and exposes a Private Key which is to be used to generate a Client ID and Secret for the Service Account to proceed with the OAuth flow)

    Additionally, GCP offers things like

    • Service Account impersonation (a User account takes on the identity of a Service Account)
    • Workload Identity Federation (this is a flavor of OAuth 2.0 client authentication, using a known non-Google account which uses Service Account Impersonation.)

    Authorization (of Google APIs)

    Authorization is notably a 2-stage process that verifies an authenticated Identity, and inspects authorization metadata (such as scopes in a JWT or information included in an "Access Policy"). This combination is used to determine if access should be granted to a specific Identity. Authorization in GCP is different when we’re talking about Google APIs and GCP resources.

    • IAM Roles and Policies are used to authorize GCP Resources (Compute Engine, IAM, Cloud Storage etc.)
    • OAuth scopes are used to authorize Google APIs (Google Sheets API / Google Maps API, etc.)

    Examples of IAM Grants

    Service Account Impersonation requires an authorization relationship between the User account and the Service Account using IAM allowing the user to Impersonate the Service Account (similar to assuming roles in AWS).

    If an Identity is going to request API scopes, it will need authorization to access the Authorization server and request JWTs. This (confusingly in my opinion) also happens in IAM. If the Identity were a Service Account, it would need to be granted the iam.serviceAccounts.getAccessToken role in IAM.

    Examples of OAuth Scope Grants

    Assuming our Identity has the appropriate authorization to request a token, it can request specific functionality offered by the Google API by including OAuth scopes in the request. The authorization server will then generate a token with those scopes, and that token will be linked to the unique identity of the requester.

    It’s important to note that a scope only defines the scope of functionality in these systems. That does NOT imply that a given Identity is Authorized to access the scope’s functionality. In most Google APIs, Authorization happens at the Google API layer. Let’s look at an example:

    If you enable the Google Sheets API (for example) and generate a token with the https://www.googleapis.com/auth/drive.file scope, the Identity requesting a token with that scope will be granted a token with that scope, but requests to the API will still be blocked by the Google Sheets authorizer until the sheet being requested is shared with the requesting Identity.

    Some scopes however, such as https://www.googleapis.com/auth/spreadsheets expose sensitive data and are by default enabled at the Google APIs layer. If these scopes are requested, the requesting Identity would in fact have access to the functionality defined by them without restriction.

    I believe this is where your question comes in 🙂

    Attempting to answer the question

    If you’re trying to prevent other developers within your organization from requesting a token that uses a certain scope that is enabled by default at the Google APIs layer, you will need to prevent the Identity from accessing that scope. This can be done a couple ways:

    • You could disable this functionality in the Workspace Admin console for the calling user (if the calling user is in fact, Internal to your organization)
    • If your application is "External", you will need to declare it through the console at APIs and Services => OAuth Consent Screen => Make External and then create restricted scopes there. I don’t suspect this quite fits your situation.
    • You could add logic in your application code which explicitly denies non-approved scopes.

    Ultimately, my interpretation is that Google puts the responsibility in the developer’s hands to request the correct scopes, and to restrict further authorization at the application level when calling their APIs. If you want to prevent an Identity from calling specific scopes, you have some degree of control over that in the Admin Console of the Workspace Account for your Google Users included in your Workspace.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search