Google provides a simple sign-in button:
https://developers.google.com/identity/sign-in/web/sign-in#before_you_begin
This button calls a function, "onSignIn" on successful login as such
<div class="g-signin2" data-onsuccess="onSignIn"></div>
I am thinking about calling one of my APIs inside "onSignIn" function and generate a token and save in users' browsers. Next time when users send API requests, I plan on using these tokens in the header to verify API access.
Is this a legitimate way of using this Google widget? Or I actually have to use OAuth and such?
Frankly, you would not need the additional complexity of token generation at your API endpoints as the Google ID tokens facilitates your exact need.
Hence consider sending the user's ID token to your API and then, on the server, verify the integrity of the ID token to accredit the user authority.
Moreover, if you require association of additional information with each user session/account the same architecture can be used with a supplementary database. For a more comprehensive guide refer this article.
Related
I would like to build a small js library that can read a specific album from my account and display the photos within as a slideshow.
In this guide (https://developers.google.com/photos/library/guides/get-started), to access the API we need both ClientID and Secret. Is there any way to access the API using some type of public key for read-only access? That way I (the provider of photos) don't have to login every time?
The Google Photos Library API is used via OAuth2 user authentication. All requests through the API are made on behalf of a user. Public API keys or service accounts are not supported.
OAuth tokens expire after a certain time, which is returned as part of the OAuth authentication request. You can use a refresh token to retrieve a new access token once it has expired. If you'd like to do this without explicit interactive user interaction, your application needs to be authorized for offline access. The good news is that the authentication client libraries handle this for you.
If you are using Google Sign-In (for example on Android), you can check if the user has already signed in using GoogleSignIn.getLastSignedInAccount(this), so you would not need to prompt again for access. You could also enable server-side access if you want to make these offline requests from your backend.
If you are using any of the Google OAuth client libraries, you can specify the 'offline' parameter as part of the initial sign-in request. For example in Java, you would set the access type: .setAccessType("offline") on the GoogleAuthorizationCodeFlow.Builder during creation.
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
We have a web server using Google Sign-In to authenticater and authorize for API access (Classroom). We need the sign-in part, so we're using init() and signIn(). We cannot use authorise(). Also, we're not signin in with particular scopes, as we just need identify for normal usage.
The logged-in user can enable a feature that requires offline access on behalf of his/her account to the Google Classrom API. We call grantOfflineAccess() with two scopes related to Classroom to get an authentication code, which is stored for later.
On the server side, we have a gRPC service that doesn't expose any web front-end. We're using C#/.NET with the Google API Client libraries.
I implemented an IDataStore that can respond to TokenResponse requests by either calling AuthorizationCodeFlow.ExchangeCodeForTokenAsync with the above code, or return the last TokenResponse stored in the database. When (well, "if") IDataStore.StoreAsync is called with a new version (normally after a token refresh was required), it saves it again in the database.
My problem is that ExchangeCodeForTokenAsync returns me a TokenResponse without a refresh_token. This means the access_token is only valid for 60 minutes. I would need to intercept exceptions at the service call level to call ExchangeCodeForTokenAsync again (if that works!), instead of relying on the Google API Client Library handling refreshing automatically all nicely.
What could be preventing ExchangeCodeForTokenAsync from returning me a refresh_token?
Thanks.
Well, I found the answer in this other question.
The refresh_token is only provided on the first authorization from the user. Subsequent authorizations, such as the kind you make while testing an OAuth2 integration, will not return the refresh_token again. :)
I simply removed my app from my Google account's authorized apps, and my next ExchangeCodeForTokenAsync call returned me a refresh_token.
Background I have some experience implementing Oauth1a and Oauth2 as a client to connect to 'trusted' 3rd party services (twitter, facebook etc), but first time implementing the resource/authorization servers.
I have a basic but not strong understanding of different grant types, and how Oauth attempts to solve the authorization of a user/resource, while protecting user information (login information etc).
Scenario: we are creating a client-side application (reactJS) which must submit some basic information to a WordPress site. We control (are the authors of and will host) both react and WordPress on the same server.
We are using WP Rest API:
http://v2.wp-api.org/
And Oauth server plugin for wordpress
https://en-ca.wordpress.org/plugins/oauth2-provider/
Question
The further we get into implementation, the more I ask, what security to I gain at all by adding Oauth in this scenario?
For development and testing, the permissions callback on the POST to our REST endpoint is TRUE (open to any request), and now we are trying to secure it so only our application can submit information to WordPress.
The author of the Oauth server for WordpPress describes for this:
The access token used to preform a CRUD WP REST API action MUST has been acquired via the password grant type (user credentials).
Which requires embedding the following in the client:
client ID
client secret
wordpress user ID
wordpress user password
since:
The access token MUST be assigned to a user id with the correct
WordPress capabilities to preform the CRUD action.
Just to get back an access token.
Note: users do not log in via our react application. The application itself acts as one user in this case.
I must be missing something, exposing the WordPress user name and password seems less secure than skipping Oauth completely, leaving the POST endpoint open, and implementing some kind of submission abuse check, via submission rate, IP or other.
With Oauth2: Someone in control of the client can watch the XHR request and retrieve all information necessary to submit malicious data.
Without Oauth2: someone could use one of many discovery techniques to find our public endpoint and try to submit malicious data.
Things which I may be missing: should I be encrypting/hashing the password, secret, ID etc before embedding in the client?
Should I be separating out our authorization server from the resource server?
Have I missed the point, and Oauth is not a good candidate for this scenario?
Any insight or clarification greatly appreciated.
I'm using dropbox chooser but the user needs to login first, and I want to avoid this using a Generated access token it is possible using only the chooser?. the documentation says:
By generating an access token, you will be able to make API calls for your own account without going through the authorization flow. To obtain access tokens for other users, use the standard OAuth flow.
but this is only able using the API? or how can I achieve this to avoid letting the user know the password? im only using one single account.
No, this isn't possible. The generated access token is for the Dropbox API, which is separate from the Dropbox Chooser. The Chooser is just a pre-built UI component that runs from the official Dropbox web site. The only way for the user to auth to it is by signing in to the Dropbox web site.
If you do just need access to your own account, and not the accounts of your end-users, you should use the API though, e.g., with a generated access token.