I'm trying to configure an API connector in bubble IO to work with a discord bot.
Normally if I wanted to use the API connector with a simple user I know how to make it work Oauth2 user-agent flow, with redirecting the user to the authorization page.
With the bot , the case is supposed to be simpler, by just using an access token for the bot, that I have. Problem is that I dont see how to configure it under oauth2 user-agent flow.
Perhaps with oauth2 custom token? and if so, how to configure the headers?
Thanks
Related
I am building a React-based SPA that communicates with a spring-boot backend via a REST API. I need the user to be able to log into their Microsoft account on the browser client (the SPA) and I need the backend service (spring-boot app) to be able to query Microsoft's Graph API on behalf of that user.
After reading up on the Oauth2 flows, the authorization code flow (not the PKCE flow, just the regular authorization code flow) seems the most appropriate. The browser client could let the user log into their Microsoft account, retrieve an authorization code, and send the authorization code to our backend service via HTTP request. The backend service (which is trusted and can safely store a client secret) can then request an access token, make requests to the Graph API directly (meaning that the SPA would never need to make any requests to the Graph API), and silently refresh the token as needed.
However, I cannot see any examples of anyone using this flow to access Microsoft's Graph API.
Looking at Microsoft's documentation, it seems like they recommend using the on-behalf-of flow. But this flow requires the browser client to request an access token and then use that to communicate with the backend service (which in turn can communicate with the Graph API). It doesn't make sense to me why the access token cannot be requested on the backend using a client secret. Wouldn't this be a more secure and preferred method than having the client retrieve the access token, as is done in the on-behalf-of flow?
The Oauth2.0 site, recommends that SPAs should either use the authorization code with PKE or the implicit flow, but I do not see an option to use the standard authentication code flow for SPAs. Should I take this as an indication that SPAs should not be using the standard authorization code flow as I described earlier?
Despite not finding a clear-cut example of the standard authorization code flow in Microsoft's documentation for a react frontend + java backend, I tried to go about doing this myself. However, using the #microsoft/mgt-react and #microsoft/mgt-element libraries to do this are not straight forward. For example, the #microsoft/mgt-element notion of a Provider supports a call to retrieve an access token, but doesn't clearly expose the authorization code. If I wanted to do the authorization code flow described earlier, it seems like I would need to use raw HTTP requests, which I know is not a recommended way of accomplishing this.
Summarizing my questions:
What OAuth2.0 flow should I be using: 1) authorization code (access token is retrieved by backend service using client secret), 2)
authorization code with PKE (access token is retrieved by client), or
3) on-behalf-of flow (access token is retrieved by client, seems to be an extension of PKE flow)?
If using the on-behalf-of flow, does the SPA just include the access token in the header (marked as 'bearer') and the backend service just
includes that same header to query the Graph API, or does the backend
service need to request another token before querying the Graph API?
Agree with #ch4mp to call graph api directly in SPA if it's allowed. If not, then I recommend you using on-behalf-flow or client credential flow based on your requirement.
Let's come back to your requirement -- call ms graph api in a springboot api project. First, let's see one of the graph api getting user api. You can see permission types here: Delegated which means call graph api on behalf of the user, Application which means calling api on behalf of the application(your spingboot api project) itself. If you want to call api behalf of the user, then you have to use on-behalf-of flow. This is because the api project which will be considered as a daemon application, so the project itself doesn't have a UI page to let users enter username/password to sign in and get authenticated.
You can certainly use ROPC flow which have to pass the username/password to api but I really think it unsafe, so I don't recommend.
If it's not necessary for you to call graph api on behalf of user, you can certainly take client credential flow into consideration. But pls note here, application type api permission is a "large" api permission which always have name like User.ReadWrite.All, Mail.ReadWrite.All and it always means the application can not only query user information but also be able to modify user information.
If you want to use on-behalf-flow, then you may review this answer and it explained the whole progress...
I would use authorization-code flow (with PKCE) to get an access-token and then refresh-token flow to "maintain" this token, both from client.
Authorizing the request to your resource-server with this token only makes sense if Microsoft authorization-server is your main authorization-server. Otherwise (user also logged in with an authorization-server of your own or not using OAuth2 betwean React and backend), you can still send Microsoft access-token in request body.
In any case, when issuing requests in the name of the user from the backend, do as you suggest: just set the access-token sent by the client as Bearer Authorization header (token is retrieved either from Spring security context or request body). Backend fetches a new access-token (using client-credentials flow) when issuing requests in its own name (without the context of a user).
Side note: have you considered calling Microsoft API directly from React client? If you don't have to store the result of that call on your resource-server (i.e. call graph API to display data and store only what user selected from that data), that would save quite some latency on the client and costs (network and CPU) on the backend.
I am trying to integrate Microsoft Graph API with my Django backend application. I want to be able to read, manage and send emails on behalf of users.
The frontend is built with React
My issue now is how the authorization flow will work. I want users to authorize the app(prolly using Oauth) on the frontend after which I will get some kind of access code that I can save on the backend and subsequently use to make requests to the graph APIs on the user's behalf
Pls, how do I achieve this flow ??
Any help will be appreciated. I have been scrambling through the docs all day, need someone to point me in the right direction
Get access on behalf of a user:
Follow this documentation for more information: https://learn.microsoft.com/en-us/graph/auth-v2-user
I'm trying to allow GitHub Actions to call my REST API that is protected with IdentityServer4. I take a look on GitHub docs about its OIDC and I understand that I can request for ID Token inside Actions. The question is how to get access token from IdentityServer4 with this ID Token so GitHub Actions can invoke my REST API?
For a client to get a ID-token, then a user must be involved to authorize the client so that you can get the ID/access token. (using the authorization code flow).
A better approach might be to use the client credentials flow, that is used for machine-to-machine communication and you can configure a client definition in IdentityServer that issues an access token to your GitHub action using a simple username/password (client/clientsecret). That is the simplest way to get it to work. In this flow there is no use/need for any ID-token.
see https://docs.duendesoftware.com/identityserver/v5/tokens/requesting/#machine-to-machine-communication
Is there any way to send OTP only using React(with Vonage or Twilio)?
Twilio developer evangelist here.
If you are looking to send an OTP via SMS using a service like Twilio then you will need a back-end of some sort. That back-end does not have to be written in Node.js, you just need a server-side component.
The reason for this is that Twilio, and other APIs, give you a secret, in Twilio's case it is called an Auth Token, that authenticates you with the API and lets your account send those messages. If you try to make calls to the API directly from within your React application, you would expose that Auth Token and a malicious user could take it and use it to abuse your account.
I wrote a post on how to send SMS messages using React, Twilio and Node.js that might help you.
If you are trying to send OTP codes, you might find that the Twilio Verify API is actually better suited for this. It is a dedicated API for sending and verifying OTP codes. This blog post shows you how to build your own Verify service using Twilio Functions. The benefit of Twilio Functions is that you don't need to run your own servers, you can host the functions in Twilio's infrastructure.
Let me know if this helps at all.
Can someone help to find a solve how to write this functionality on AngularJS?
Have java rest API and authorization server on one port and ui on other. Back-end authorization made by oAuth2. Need to make UI authorization. can someone help, please?
Thanks and best regards.
if you are using AngularJs 1, you can use Satellizer. It's an AngularJs library to easily implement a token-based authentication.
Here is the GitHub link -> https://github.com/sahat/satellizer/
It is compatible with OAuth1, OAuth2 and has built-in support for the most popular provider (Google, Facebook, GitHub etc). I am using it for a current project and it perfectly works.
Please provide some details if you need any further help :)
If you are using oauth2 server you can authorize you rest enpoint via oauth token.
Make an http call at the loging form the frontend to necessary rest enpoint and take the relevant token and store it in the local storage.
Then use and http intercepter to attach the authorization header to each and every request.
If you need any codes or example drop me a message.