I am building a speech to text application for browser. Right now I am recording and sending the voice from frontend to backend, from backend calling the google api for converstion. Now the problem is processing time is high.
what I need is to call the google api from frontend itself. problem with this step is api key is getting exposed to user and leads to security issue.
So can I generate a session based auth token for speech to text api, which will be valid for client for some duration of time. any tutorial link will also do.
Just about everything Google creates supports OAuth 2.0. Text to Speech certainly does.
Authenticating is easy. Here is a link on how to use OAuth 2.0 with Google APIs.
Using OAuth 2.0 to Access Google APIs
Here is link on how to integrate Google Sign-In to your Web App:
Add Google Sign-In to Your Web App
And a link for adding OAuth 2 to your backend server in PHP:
Using OAuth 2.0 for Web Server Applications
I would use Google Accounts to start. Google Sign-In makes this easy to implement for the client. Either implement OAuth 2.0 on the backend (recommended) or on the client.
Once you complete the OAuth 2 flow, you will have a token that consists of an Access Token, Refresh Token and Client ID Token. You will use the Access Token to authorize API calls. You will use the Refresh Token to refresh the Access Token as it expires every 60 minutes. The Client ID Token will provide you with their identity information.
Related
I have a django restframework backend and a react frontend that uses google social auth to authenticate human users. The flow is a relatively simple JWT flow.
The user goes to my website
The user logs in with their google account
the google window sends a credential to my backend
the credential is verified on the backend
I send back an access token that allows the user to use my app which makes rest calls to my backend
I would like to generate a similar access token to pass to the backend so that I can access my api from lambda functions.
Is it possible to use the client_id and client_secret from my google console credentials to generate the same type of token to send to my backend? I've also looked into google service accounts, but this seems to be used specifically for accessing google services, not a generic API that is simply protected via google authentication.
If none of the above options work? How would you recommend I authenticate machine users via google auth?
I am working on SPA and HTML5 Mobile application that's consume my server application via rest api. Server app connects to Google Adwords Api and then sending data to client app. My question is: is it possible to use google oauth login as login for my server api. And how?
Do I need to use FOSOAuthServerBundle?
Best,
Antonio
This is the flow for this use case: https://developers.google.com/identity/sign-in/web/server-side-flow
And after this you can use google token as your api token, or build your own oauth and use your own token.
Also it is possible to use FOSOAuthServerBundle with custom grant
Im building rest api (using PHP, Laravel) which is used by mobile applications. The api basically is just commenting system.
Im planning to allow users to log in (to use this api) using their Facebook/MS/Twitter etc accounths using OAuth 2.
Flow would be something like this:
Authenticate user in mobile client using (user) selected OAuth provider
Get access_token (also maybe username/email) from OAuth provider and save it to mobile client
User access my rest Api (leaves comment), I include OAuth auth token to request
In server side I validate this token
Does this make sense? Is there any better ways to build this kind of system where the actual authentication server is completely different than the resource server?
I am developing a REST API. Currently I am trying to make it minimally secure. I am asking this question because most of the posts I found about this subject were quite old.
For authentication I found this schemes:
Basic authentication
AWS authentication protocol
OpenID
OpenID Connect
OAuth pseudo authentication
Basic Authentication and AWS authentication maintain the requests authenticated after a firts authentication because they keep sending signed requests.
I don't understand how the OpenID and OAuth authentication maintain a (second) request autehnticated? Do I need to check the access token with the OAuth/OpenID server per each request? How does this protects the REST API from receiving requests that have been altered?
Any other schemes that you recommend, advices or reading material about the subject are always welcome.
I'd talk about OAuth here
i) You create a web app and want to use google's OAuth API's.
ii) You register your app here and get credentials.
iii) Now, in the app you'd use Google's SDK to open the login page, enter your credentials and Google would verify it and send you access tokens and refresh tokens.
iv) You would make REST call to google's APIs with the access token and fetch user's data.
Now, coming to the question you asked -
An access token generally lives for 1 hour. Yes, any authenticated calls that you need to make to any of Google's API within one hour could be made with the same access token.
There is another type of token - the Refresh Token. At any time, your app can hit the provider's token exchange endpoint and exchange the refresh token for - refresh token + access token pair.
Now again, you have an access token that will help you for one hour and a refresh token that can be exchanged any time.
Refresh tokens live for as long as you want, till the time the user explicitly revokes permission to your app. (Tells Google that it doesn't not want you to access his resources!)
OAuth would make your REST API secure by ensuring that only authenticated and authorized clients can hit your API. But generally, OAuth is only used when there's a situation where a third party client needs access to a user's resource!
We're building a public API and clients using this API will need to authenticate, and we proposed to expose an OAuth2 API for this purpose.
However, we also have a need for authentication to be federated, so we see clients talking OAuth 2 with our API, and our API talking OAuth1/2 or SAML2 to the identity provider in the background.
The full flow being:
Client talks OAuth2 to our API.
At the start of this flow, our API redirects the client to a "Choose Your Federated Provider" HTML page.
On choosing a provider, our API talks OAauth1/2 with the provider, passing any redirects back to the client, so the user can provide login details.
Our API exchanges the access code for a access token and refresh token (API keeps these private, and uses them even if the client is off-line).
Our API generates an access code and passes this to the client.
Client exchanges the access code for access token.
The provider supplied access token/refresh token is use by the API in the background, for example to keep a Google calendar up to date, and not passed to the client.
I've not found any examples of this being done with an API. So, what is the established model for providing federated authentication for an API service?
Check out some of the info that Ping Identity provides on their OAuth Essentials page. Specifically, there is a White Paper entitled, "A Standards-based Mobile App IdM Architecture White Paper" (free w/Registration) that you should look at that talks about how you would use SAML + OAuth to secure Native Mobile Apps that require Federation. [Note: I do work for Ping]. It lays out the info flows and token exchanges that need to happen to solve this use case as well as other OAuth related cases.
HTH - Ian