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
Related
I am rather new to app development but I have the front end sign-up and sign-in form ready to go in react native. I want to send this data from the client to my AWS server to authenticate and create session tokens for each user. Online all I can find is using Cognito with Amplify. This is not a problem, although I want to be able to access the session token on both the client AND server side. Is this possible with Amplify?
I've used express as a react server on AWS in the past for Websockets, Routes and other fun stuff and was hoping to use that again since I am familiar with handling the backend logic that way. There, I'm assuming I would receive session tokens from clients and compare with what Cognito/Amplify has on record. If the session token matches, then dish out appropriate resources like an image, string, video etc. from other AWS services (e.g. S3, DynamoDB). Express would allow me to create custom API Routes/URLs in this way.
Does any of this sound like a good plan or even feasible? Are there other easier ways of achieving this? Its hard to sift through all the documentation they offer. Please let me know! Thanks in advance :)
You can use Auth. currentAuthenticatedUser after the sign up process to get session auth token and save it in the front end. If you are going to send it to the backend you will need to make a PostConfirmation function in Cognito get the access token and send it to your backend.
The best way to do it its handle everything with Amplify, if you are more comfortable with Express I recommend you to create a Rest API in Amplify. They will handle everything related with the resources access.
I recommend you to watch this Youtube Channel. He has very neat tutorials. https://www.youtube.com/user/boyindasouth
Me and my team are trying to build a React web application that requires read/write access to the user's Google Calendar in order to provide some functionality.
I would like to use AWS Lambda functions (preferably written in python) to do this, but I'm struggling to understand how can I authenticate the lambda function to read/write the user's calendar.
I have been able to authenticate to my own calendar within a jupyter notebook using the from_client_secret method, but I don't think that could work in lambda:
flow = InstalledAppFlow.from_client_secrets_file('client_secret.json', scopes=scopes)
#credentials = flow.run_console()
I suspect I need to exchange something for a token that lambda can use every time it needs to access a particular user's calendar, but how would I go about implementing that?
The Google Server to Server documentation recommends the use of Service accounts, but struggling to see how I'd implement that in Lambda. Any help would be appreciated.
We want to use OKTA for SSO but need to know if this is Synced in both ways?
In case if we are making any change in Salesforce side for User , will this be updated back to OKTA, believe not and this would need API calls.
Someone Please confirm.
Pls share the OKTA API wsdl or Link for Salesforce call outs.
Thanks in advance.
This is tricky, ultimately something has the be the master of a Users profile. Okta can push almost any record to salesforce, no problem, and it can import changes from salesforce. But, which source is authoritative ?
What I have done in the past, is I used a (I'm not a salesforce admin) trigger, so when a Users profile was updated in Salesforce, it would make a web service call to update elements of that users profile that needed to be immediately sync'd with Okta.
In this situation, there were people in a call center, and if someone updated their subscription service, they needed that to get pushed to Okta immediately so they could have Okta update that users profile in other downstream systems.
Okta uses rest, not WSDL, but you can easily build a proxy service to accept them, and convert them in to JSON Rest calls. Everything you need is available on https://developer.okta.com (including a sandbox if you need it).
There is also a postman collection, so you can get familiar with the Okta APIs. Here is the link to that: https://developer.okta.com/docs/api/getting_started/api_test_client
I'm considering using AWS Cognito as a user management system for a single page web app I'm building using React along with a Python REST API backend (Pyramid). I'm struggling to see how all the pieces fit together for my architecture (the docs don't seem to be helping me). There are many great examples of how to implement authentication into the frontend using JS. My issue is how to integrate this authentication into my backend REST API.
In my current hand rolled user management system, the frontend calls the REST API on sign-in and is given a token which is passed to API again for every subsequent request. I'm then able to use ACL's on my API functions, check permissions to access resources, etc. If I were to use Cognito and perform the authentication on the frontend (as many examples do) how will my backend know if the token is valid when it receives it with a request? Surely I wont have to call Coginto from the backend to verify this for every request? Also how can I perform checks for information such as 'is this user in the admin group' if that group is defined within Cognito? Again, calling out to Cognito for every request seems very heavyweight and cumbersome.
I did see one example where a list of valid tokens was exported from Cognito as a JSON file and kept on the backend. This seems horribly static when users could be added and removed regularly.
Is Cognito really suitable for my use case? Some high level guidance and pointers to any relevant examples and docs would be greatly appreciated!
When authenticating with Cognito, the user can have 3 tokens:
Refresh
Access
ID
For python, boto3 can interface now with Cognito. There's also this python lib wrapper: warrant, to make it easier.
Once you have the token, it is possible to pass it to the API (eg: access) and it can be checked on the server side with python-jose, as per AWS docs
To pass the token, an example pyramid /login implementation can keep the information in the session before setting the request response:
request.session['my_token'] = str(a_token)
The default cookie session factory works, though it warns that the token is not sent encrypted.
I'm trying to figure out how to implement the following authentication flow:
The user accesses a web application (most likely to be written using Ruby on Rails) and authenticates (e.g., username/password).
The client consumes data via AJAX provided by a RESTful API built on Google App Engine (Python, webapp2).
Requirements:
Only users authenticated in the web application (Rails) should be able to access the API hosted on App Engine.
Users can have different roles in the web application (Rails), and the API (App Engine) needs to know what roles are associated to the given user to restrict access to certain data.
The client should be able to call the API (App Engine) directly via AJAX, without routing all requests through the web application (Rails).
I'm looking for suggestions on how to implement such workflow. Should I use OAuth (or OAuth2) for accessing the API? Should the OAuth provider live on App Engine and the web application (Rails) ask the API for a token on behalf of the user? If so, what is the best way to allow only the web application (Rails) to request OAuth tokens? Or should I consider a completely different strategy?
Any suggestions are greatly appreciated. I'm also looking for suggestions of libraries to implement OAuth in the context above.
I suggest you use caution if you are considering implementing an API built on the Google App Engine using OAuth for your security layer. I am currently involved in a project that is struggling to solve exactly this problem. The OAuth layer over the GAE is still new and considered by Google to be "experimental". Google's documentation is minimal at this point. What there is begins here. I wish you the best if you try to proceed, and I will do my best to offer help if you do.
My solution to this same problem was to write my own three-way authentication (like OAuth):
After the user is authenticated on the RoR server, it responds with a temporary token. This token is stored on the RoR server, is good for 60 seconds, and contains the user's roles.
The browser sends this token (using AJAX) to the webapp2 server. It's like logging in on that server using just the token.
The webapp2 server forwards the token on to the RoR server to make sure it is valid.
The RoR server makes sure the token hasn't expired and immediately deletes the token to prevent duplicate requests. If the token is valid, the RoR server responds with the user's roles.
If the response from the RoR server is good, the webapp2 server responds to the browser's AJAX call (in step 2) with a cookie indicating that this user is now logged in. The session should contain the user's roles.
Subsequent requests to the webapp2 server will include the cookie so that server can respond according to the user's roles.