My app uses firebase authentication, and only users from my G Suite Domain are successfully authenticated. I have the scopes set as follows:
var provider = new firebase.auth.GoogleAuthProvider();
provider.addScope('https://www.googleapis.com/auth/admin.directory.user')
provider.addScope('https://www.googleapis.com/auth/admin.directory.user.readonly')
provider.addScope('https://www.googleapis.com/auth/devstorage.read_only')
firebase.auth().signInWithRedirect(provider)
My understanding is that I can use the access token that is returned from the above login flow for http requests to read objects from my Google Cloud Storage bucket. I insert the access token as a header like so:
Authorization: 'Bearer xyz123'
For my non-public bucket, I have Uniform bucket-level access enabled, with an IAM role that allows users from my G Suite domain to read from the bucket.
However, this isn't working, as I'm getting 403 responses for the http requests. For a little more context, I'm hosting vector tiles in the bucket which are being consumed by mapbox-gl.
Any idea where I'm going wrong here?
P.S. I am confident that this is a permissions problem and not a problem with mapbox config or the vector tiles themselves. When I make the bucket completely public, everything works just fine. What I'm struggling with is how to limit access to the vector tiles to only users within my G Suite domain.
So, what I did above was correct. However, I was missing one piece: the cors setting for my Google Cloud Storage bucket needed to be updated to replace
origin: "*"
with
origin: ["https://domain-name-where-request-comes-from.com", "https://and-dev-site-for-that-domain.com"]
Per the REST spec, the * wildcard is not acceptable when credentials are expected as part of the request.
I also needed to update the responseHeader of my cors settings:
"responseHeader": ["X-Requested-With", "Access-Control-Allow-Origin", "Content-Type", "Authorization"]
With the OAuth token inserted in the headers of the mapbox-gl request (via the transformRequset method), I could successfully request and receive the tiles.
Related
I have followed the AWS documentation for enabling an authoriser for API access using Cognito tokens.
When I test the authoriser with the ID token within the AWS console, it works fine.
On using the access tokens and trying to access via Postman I repeatedly get and "unauthorised" error (401).
I have tried the following but to no avail
Disabling and enabling CORS (both combinations)
Using the ID token instead of the access token
Republishing the API after changing the auth scope params
Deleting and recreating the API again
When I turn off authorisation the API works fine via Postman/ Browser. When I turn it back on again the problem resurfaces.
I have an SPA that uses B2C as its certification.
not AD, im using B2C.
Now I want to display user information on the SPA,
so I want to use MsGraphAPI to get data from B2C.
Therefore, we are trying to obtain an access token using credential flow.
The code is as follows
requestUri = "https://login.microsoftonline.com/{tenandId}/oauth2/v2.0/token";
var params = new URLSearchParams();
params.append("grant_type","client_credentials");
params.append("client_id","XXXX");
params.append("client_secret","ZZZZ");
params.append("scope","https://graph.microsoft.com/.default");
const response = fetch(requestUri, {
method:"POST",
body:params
});
At this time, the developer tool shows a corrs error.
The following error.
access to fetch "https://login.microsoftonline.com/{tenandId}/oauth2/v2.0/token" from origin "http://localhost:3000" has been blocked by CORS policy.
How can I resolve this?
SPA is available at http://localhost:3000.
Is the localhost no good?
The purpose of authenticating is to get user information. You can insert any attribute into the token, and then parse the id_token to display the users profile information in your application. Calling MS Graph API for this seems counter intuitive.
Next, you shouldnt be using client_credentials in your SPA, those are secret credentails, and should only be used by your server. By exposing those credentials in your SPA, any user could extract them and use them to read your entire directroy store. This is why you are getting a CORS error, it's never supposed to be running on the client browser.
I have application with backend and frontend. We are using JWT token for the authentication and Authorization(A2). Now we are planning to use express-gateway as an API gateway (AG) so that backend can be unload from routing and other protection heavy load and shift that burden to AG. Now since we are using AG shall we remove the A2 logic from backend and whatever request comes to backend (every request will be routed from consumer to backend via AG) we treat it as authenticated user and process the request, no need to verify again. If yes then we will still need JWT token to get the payload to extract the information like email id, role etc. For that should we pass the token from AG to backend. Also backed might have different kind of things on payload than EG. How to tackle that.
To pass authentication information on to a server, you need to use the request-transformer policy to add the information to the request headers going to the server, e.g. the following fragment adds a header named eg-consumers-firstname:
- request-transformer:
- condition:
name: authenticated
action:
headers:
add:
jscode: 'req.headers["eg-consumer-firstname"] = consumer.firstname'
The JS variables you can use in jscode sections is not particularly well documented, but you have access to everything in models/users.js.
In general, you can often adjust the gateway.config.yml such that scopes restrict which apiEndpoints (paths) are available to a given user; this is a better way to prevent unauthorized access then doing the processing on the downstream server side, which should do an independent check in case the API gateway has been compromised.
Situation: I run a Django app in the web, where logged-in users can also download .pdf files (non-public, with specific restrictions, depending on user rights). The most convenient way to do so (e.g. in S3) is to use a time-restricted, pre-signed URL because they open immediately in the browser, plus the app server does not have to handle additional traffic.
Problem: Backblaze B2 oviously does not offer an explicit method for creating presigned URLs to download non-public files directly in the browser.
Generating the api URL and the authorization token, and fetching the file from the object store happens at the app server level and the process is not exposed to the "ordinary" user.
But in the end, the API operation "b2_download_file_by_name" just uses a GET request, which means I can add the authorization token to the request's URL using "?Authorization=123xyz........". This way I get a presigned URL that works perfectly fine in the browser to allow access to a specific non-public file for a limited time. (Please note: B2 downloads can be restricted to files with specific prefixes [like s3 pseudo-folders], but if the specified "prefix" is long enough, I can make the auth token specific for one file.)
Question: As I wrote above, usually the authorization token is not exposed to the user. Now, if I make the URL visible, does this imply a security risk? In other words, could a user that posesses one or many tokens, extract the general access key from the token, or is the token encrypted well enough to avoid this?
According to the documentation for the b2_download_file_by_name call you can use the download authorization in a URL in the way you describe.
An authorization token can be provided in the URL query string instead of being passed in the HTTP header. An account authorization token obtained from b2_authorize_account will allow access to all files in a private bucket. A download authorization token obtained from b2_get_download_authorization will allow access to files whose names begin with the filename prefix used to generate the download authorization token.
However it seems that the expiry time set in the b2_get_download_authorization call is being ignored so the resulting URL never expires which is not secure of course. I have a support ticket in with B2 about this so hoping for a solution.
I am building a program that will list albums/folders and images from my Amazon Cloud Drive. I am able to authenticate and get a token by following the instructions here at amazon public apis.
I am having trouble with the next call to get my endpoints described here under Account API.
Using get
GET : {{metadataUrl}}/account/endpoint Gets the customer end-point against
which REST queries will be executed.
So my request looks just like this in fiddler and on my site just like it is described on the Amazon site here under Get Endpoint. The only differences is the token for obvious reasons.
Sample Request:
GET /drive/v1/account/endpoint HTTP/1.1
Host: drive.amazonaws.com
Authorization: Bearer
Atza|IQEBLjAsAhQ5zx7pKp9PCgCy6T1JkQjHHOEzpwIUQM
My response is:
{
"message":"Authorization header requires 'Credential' parameter.
Authorization header requires 'Signature' parameter.
Authorization header requires 'SignedHeaders' parameter.
Authorization header requires existence of either a 'X-Amz-Date'
or a 'Date' header. Authorization=Bearer"
}
What I am expecting:
{
"customerExists": true,
"contentUrl": "https://content-na.drive.amazonaws.com/cdproxy/",
"metadataUrl": "https://cdws.us-east-1.amazonaws.com/drive/v1/"
}
I did find some information about building the objects in my response from amazon, however, it's not listed in the documentation on the amazon developer site. Is this something new that has not been updated in the docs or am I doing something wrong?
I had a new line between Authorization: Bearer and my token Atza|IQEBLjAsAhQ5zx7pKp9PCgCy6T1JkQjHHOEzpwIUQM. After removing the new line my issue was fixed..