Google ClientLogin authorization for multiple services - google-authentication

in the HTTPS request sent to Google ClientLogin https://www.google.com/accounts/ClientLogin
i send a parameter with https request named "service". this will be the Google service i need to authenticate with.
in my application i want to be granted access to both "contacts" and "google docs" services. can i send two "service" parameters request to ClientLogin? one for each service? will this work or is there another more clean solution?

According to a Google employee it is not possible to get a token that is valid for multiple services:
A Client Login token only works for a single service, but you can
request more than one token. For example one for Calendar (cl) and
another for Contacts (cp) then you can use the appropriate token for
the following services requests.
I can't find anything in the documentation about getting multiple tokens for different services with only one request so I think the cleanest way is probably just doing 2 requests and keeping the 2 tokens.

Related

Pass Cognito User Info to HTTP Integration

I've been exploring utilizing Cognito User Pools for authentication and API Gateway to feed client requests with auth tokens. I'd basically like to have a simple react app that utilizes the cognito sdk for authentication. Then use the authentication to make requests via the API Gateway to an express application, hooked up to cognito user pool auth. It would be ideal to have user information available in the express app - seems pretty simple to me.
I've seen many articles and forum posts about how to retrieve Cognito User Info in the context of a lambda function but nothing about how to retrieve Cognito User Info in the context of an HTTP Integration.
Is this possible?
Yes, it is possible, and can be achieved in, at least, two ways:
Proxying requests with original headers
If you enable "Use HTTP Proxy integration" in your HTTP integration, the API Gateway will act as a proxy and forward any headers in the request to the backend (and same from the backend response back to the client). This means that the JWT will reach the express application in the same header the client sent it, where it can be decoded and the claim(s) retrieved.
Using request [and response] data mappings
Another way is to pass the required claim(s) in the Path/QueryString/Headers mappings for the Integration Request, using context.authorizer.claims.{claim} in the mapping, e.g. context.authorizer.claims.email. You can see the documentation on setting up the data mappings and also the mapping reference for more variables that can be used. Please note that for context variables the right syntax to use is without the $ prefix.

Integrate Cognito with API Gateway and static credentials

So we built our service to give our users API Keys to access API Gateway and our service. Gateway acts as an endpoint for our Lambda functions.
The problem is, we got an email from Amazon saying that we hit our API Key limit of 500 keys. They said that we shouldn't be giving users API Keys because keys are meant for integrating with other services, not users. They said we should be using Cognito User Pools and our limit can't be increased.
The problem is, our users build HTTP requests in a tool called ManyChat - a tool for building chat bots.
Our users build dynamic requests and then save their chatbot to use that dynamic request. Our users can't go back and refresh those credentials as is necessary with Cognito tokens. The authentication method will have to use a static API Key I believe.
Is there a way to manage our users' usage while keeping the authentication credentials static?
1) Update 401 Unauthorized response template as per your need so that it contains the WWW-Authenticate header set to 'Basic'.
2) Create a custom authorizer that match your credentialand and retyrn response.
https://medium.com/#Da_vidgf/http-basic-auth-with-api-gateway-and-serverless-5ae14ad0a270

Enable CORS for Azure Rest webapi application

I have simple jQuery page that makes calls to azure restful API to get the status of VMs.
I'm facing a problem that it's complaining about Cross-Origin Resource Sharing and I can't find where to set that for the Web app/API I have.
I'm using client credentials grant to get the token
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow
I have finished my testing and when I tried to do the calls from jQuery/JS I got the CORS problem.
My setup involved:
From Azure portal, I used App registrations to register an app of type "Web app/API", give it a homepage address "this is where it lives", created a key.
Using
POST https://login.microsoftonline.com/<tenant id>/oauth2/token
grant_type=client_credentials
client_id=application id
client_secret=application key
resource=https://management.core.windows.net/
Am I missing any missing anything? my search keeps leading me to Azure hosted apps
Okay, here is how to do it in short:
Add Function App (charge per request)
Open the Newly created function app
In Proxies, select that from the right list
Give it a name, route template will be your new endpoint URL, backend URL is your login endpoint eg: https://login.microsoftonline.com//oauth2/token
After that, back to your function app, select the platform feature tab, Select CORS, delete all of them and enter your application URL or simply a *
You can be more specific with these, but this is enough to get the token. And all the other endpoint didn't have CORS problem.
Good luck.
You cannot use a client secret from front-end Javascript.
Your client secret will be public, it's basically your app's password.
Client credentials grant is for back-end applications.
You need to use e.g. the implicit grant flow with ADAL.JS/MSAL.JS to acquire tokens.
Your front-end app also should be registered as Native since it is a public client.
Here is a sample app: https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi
Oh, and the CORS error comes from Azure AD's token endpoint.
You cannot do anything about it.

What is the best way to work with REST WebService and Session management?

I want to develop a java application with REST web services, as it will have browser client and mobile client. My concern is session management, could anyone suggest me what is the best and recommended way to manage the session. Scenario: An employee will login and then he will call for other services like salary details, work hour details, permanent address etc. Here all these details will be exposed as individual REST web service. After login of employee any further request like request to see the permanent address will be REST service call. Please provide me the best and recommended solution.
In scenario where you want to support mobile as well as web application, token based authentication and session handling can be a good approach you can follow.
You can either go with existing token based third party API's like (OAuth2) or you can create your own token based session management system.
Proposed Solution :
Whenever your application get's first hit create and save the random token (say 64 bit random generated string).
Mobile and Web Application will save this token in it's memory and send this token in headers every time it makes a webservice call.
You will need one web service which will accept all your request and redirect request to your application only when token is valid. If token is invalid it deny access to the applicaton service. (Gateway7 works in same way)
You can pass a key for every webservice url. say app.xyz is my identifier. Which points to xyz url of my application 'app'. So your url's will be maintained at server and client will only have identifiers and one URL of your token validator application say 'Token Handler'.
So in this 'Token Handler' application you can set your session time. This will be time for which your token will be valid. So if you don't get any hit from that particular user for say 15 minutes then you will mark it as invalid token for next request.
Please let me know we can have discussion if you need any additional help on it.

angular2 login page for a web client to a back-end REST service

I am writing an Angular2 client web application client as a front end for a REST services providing access to some resources.
The REST service is protected with basic HTTP auth, and allows unauthenticated access for some of its endpoints (for instance GET /freeresource), while requires user/password authentication for other endpoints (say GET /protectedresource, or POST /freeresource, etc.).
For my Angular2 client, I would like to implement a loging page allowing access to the web application with the same ":" accepted by REST service. For this I'm following this tutorial : https://medium.com/#blacksonic86/angular-2-authentication-revisited-611bf7373bf9#.myifbz656
The problem is that the above tutorial assumes that the backend REST service has an explicit /login endpoint returning an authentication token to which you post your credentials, while my REST service does not have such an endpoint, but just returns an authorization error when passed missing or wrong credentials for endpoints that require them. I didn't find any alternative article or tutorial for a situation like this.
What is the correct way of proceeding in such a case? I could "simulate" the /login endpoint by accessing for instance a protected resource with username and password read from the app login page and trying to access a protected resource GET /protectedresource, considering as a failed login if this call returns an unauthorized error, but clearly this is not a satisfying solution (what today is a protected resource could become freely accessible tomorrow, for instance), so what is a "clean" way to implement the web app login in this case?
You don't need to simulate the /login endpoint. You just need to know on the client accessing which resource requires authentication. You can implement the same "CanActivate" method from the tutorial, and write your service call to pass credentials (or use the local storage if the user is authenticated already) when you make the REST call. If your REST endpoints require authentication every time, get them from the user at the login page, store them in the local storage, then pass them to the endpoints that need authentication.