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?
Related
My I am trying to deploy azure AD to my application because I want to expose some of my APIs to users but I need to make sure only people that are authorized can use the resource.
I have never worked with azure AD before and I am a little lost in all the documentation.
What I need is to be able to recover a token on behalf of the user in order to authenticate them. The application does not have any webpages and I do not want to introduce any. I want to be able to grab the token, authenticate the user, and then release the resource. I expect that the endpoint will be accessed through python, java or postman.
Example of basic flow:
call security function/api in app
validate user cred (or any other type of validation)
return token if authenticated
validate token and return response
5.authentication allows user to call apis
I have just explored the authorization code pattern that azure AD offers but this requires an interactive step from what I was able to test so its no good.
I would like to be able to do something like the example flow
In case my question hasn't clued you in I am very new to this so any help is appreciated
Thanks in advance
I agree with #Gopal you can make use of client credentials flow that does not require user interaction to call an API.
You just need to enter Azure AD client application’s ID, Secret, scope to generate the access token and use that access token to call the API via Postman or in your code.
I created one Asp.net core API in VS studio and used Azure Ad authentication to call the API.
I tried accessing this API via Postman App with different flows that you can try :-
Client Credentials flow:-
GET https://login.microsoftonline.com/<tenantID>/oauth2/v2.0/token
grant_type:client_credentials
client_id:<appID>
client_secret:<secret>
scope: https://management.azure.com/.default
Results :-
API can be accessed by the Access token generated by the client app with its secret and scope.
Alternatively, you can make use of Implicit flow which will ask for user credentials via browser.
Implicit flow :-
Here, Your log in page pops up while asking for access token and you need to enter user credentials to get access token and fetch API.
Get the token and hit the token to fetch the API like below :-
Browser Pop up:-
Access Token:-
Now, copy our API URL from browser and try to access the API :-
Results :-
You can find the code samples below :-
https://learn.microsoft.com/en-us/azure/active-directory/develop/sample-v2-code#web-api
I am currently using Firebase Authentication in my app using the built-in OIDC providers (Google, Facebook etc.). Is it possible to use Okta as an additional OIDC provider with minimal modifications to my app, meaning Okta should behave just like any other built-in provider? Firebase Auth apis, such as firebase.auth().currentUser and firebase.auth().onAuthStateChanged() should still work.
The doc page for Custom Authentication talks about getting a custom token from an auth server, but does not clarify if that's an OAuth access token. Is there an example of Okta integration or a generic OIDC integration that works seamlessly with Firebase auth?
There's no built-in Okta provider for Firebase Authentication, but if you have an existing authentication flow for it, it's fairly easy to integrate it into Firebase as a custom provider.
It's a 6 step process:
You gather the user credentials on the client.
You pass those credentials to a trusted environment, either a server you control, or Cloud Functions.
On the server you verify that the credentials are correct according to Okta, typically by calling a server-side API they provide with a key you provide.
You then use the results of that call to mint a new ID token for the user. This is a JWT, not an OAuth access token.
You pass back that ID token from the server to the client.
The client then calls firebase.auth().signInWithCustomToken(token) with the ID token, to sign in to Firebase Authentication.
I need to enable SSO between my customer's website and my API.
The customers website doesn't use Auth0 but allow users to login using a few different social providers like Microsoft and Google.
My API is secured using Auth0 and also supports Microsoft and Google authentication via Auth0. If my customer sends the JWT token received when the user authenticated with Google with their request to my API, will Auth0 authenticate the user even though my customer doesn't use Auth0?
Google/Microsoft auth is OAuth. OAuth is an explicit grant between the user and one particular application. It cannot and won't be shared with your app. The user would need to do a separate OAuth flow with your application to grant it access. There is no way around that.
However, given that this is an API, the more likely scenario is that the user shouldn't auth with your app at all, but rather, it should be the customer's application that auths and then works on behalf of the user. As such, you'd just set up the customer's application as a client and given them client credentials to use. Then, the user auths with the customer's website, the customer's website auths with your API via its client credentials, and then the user in effect works with your API via the customer's application as a go-between.
No , if your api application is protected by Auth0 and use external providers , after authentication from external providers and back to Auth0 , Auth0 will validate the token issued by external provider ,decode token , read claims , issue Auth0's own token and implement session management . So that your api application only accepts tokens which issued by Auth0 and validate tokens use Auth0's key-pairs , it won't accept other provider's tokens .
You can make your client application and api application both secured by one identity provider(Auth0/Google/Microsoft) .
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.
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?