I want to aggregate my clients' ad account into my business account automatically.
The client is already logged in via oauth2 process in my website and grant the permissions, ["ads_read", "ads_management", "manage_pages"].
I'm succeeded to request access for the client using the endpoint POST /<business_id>/client_ad_accounts.
Request image in the client Ad account setting page:
And, There is a problem.
I want to accept this request programmatically using the client's ACCESS_TOKEN.
POST /act_<client_ad_account_id>/agencies
-d "business=<my_business_id>&access_token=<client_access_token>"
But, I have a error message (#10) Ad account <client_ad_account_id> must be managed by a business account to approve agency access.
Is it possible to accept this request programmatically? If that's possible, what should I do?
self answer: Connect client page to the client's business account and add permission business_management. Then, everything works fine.
Related
We have a system that supports social logins and we have a feature that users can download api access key and secret key to make APIs programatically.
But when a user account is deleted from social login provider the user can't login in the system. But the same user can access APIs programmatically. Is it possible to stop the API login as well ?
Unfortunately this can't be done, unless the social service supports publishing some kinds of events about deleted users (though I highly doubt that anyone would be doing that). Maybe there is another way to verify for you whether a given account exists in the social service (by calling some endpoint, for example). Then you can periodically check with this endpoint which of users exist. Or call this endpoint when you get a request to the API and verify if the user still exists.
I am currently in the process of wrapping my head around OAuth2 and OIDC. I know what all the grant types are (namely the grant types "Authorization Code", "Client Credentials", "Device Token" and "Refresh Token"). However, these four grant types do not include an option to pass a username and password. I get that there is a password flow, but this grant type is forbidden according to the Security Best Practices.
I also get the problems with the password flow, but I do not know how to replace it - after all, the user needs to enter their credentials at some point.
Is there anything I am missing? I would have thought that there is a single, trusted client that uses the password flow and that all other clients are redirected to, when a user wants to sign in.
I think I understand this issue a little better now although I may be projecting my own requirements on to your question a little bit here.
The Password Grant flow previously allowed a single client to authenticate multiple end users with the API. Let's say you run a shop and your delivery company have an API. Your shop sets up a client and each of your staff members can log in to their own account via the client.
In this case to log in they need to provide the client ID and secret as well as their username and password which Password Grant allows.
However in order to pass the user credentials to the API, the client needs to handle them in plain-text.
That's where the Authorisation Code flow takes over. Essentially it defers the login process to the API and the user enters their credentials there.
But what if your client is the API user? The shop users log in to the shop application and the shop application authenticates with the delivery API as the shop not the end user.
The Client Credentials Grant is the appropriate choice here. The documentation talks about using the Client Credentials Grant "outside of the context of a user" but this doesn't mean that the client itself can't be associated with user within the API identified and verified by the client ID and secret.
In this case the client has all the credentials is needs to handle logging in to the API without requiring intervention from the user.
In any situation where the API handles the authentication of an end user, it is fair to expect the user to be actively involved in the process and therefore to be able to interact with the login screen provided by the API via the Authentication Code flow.
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
I want to pull periodic reports via Google Seller API. Is there a way, to login into Seller account without having to go via regular OAuth redirection ?
It would make no sense to try to use a service account to access AdEx, which is owned by a user account. You need to obtain a refresh token for the user account, store it somewhere, then use it to obtain an access token whenever you need to access the API. This answer gives the steps to follow How do I authorise an app (web or installed) without user intervention? (canonical ?)
I am trying out Office 365 Rest APIs.
I have registered application with Azure AD.
It has following permission set: Exchange: Access All User's Mailbox, Full Control on User's Calendar, Full Control on User's Contacts, Full Control on User's Mailbox
I have generated access token with admin grant which has global admin privileges.
Sent following request 'https://outlook.office365.com/api/users/me/messages' which resulted in correct results giving me all messages in current admin's mailbox
Sent following request 'https://outlook.office365.com/api/users/{another user's email}/messages'. This resulted in following error
"u'error': {u'message': u'Access is denied. Check credentials and try again.', u'code': u'ErrorAccessDenied'}}"
Please let me know if above steps are wrong ?
If they are wrong, is there a way to fetch emails from another user's mailbox as I have admin credentials ?
Thanks.
You need to use a service account as described in this blog, for your scenario and the app will be able to make calls to interact with any mailboxes in that tenant. The reason your request to use another user's mailbox is failing is because the request will be approved only if the app and user have permissions to access the other user's mailbox. In your case, the admin has permissions to the other user's mailbox. But the app, assuming you used OAuth code flow, to get the OAuth token, only has permissions to the authenticated user's mailbox.
Also, you don't need "Access All User's Mailbox" permissions for REST APIs, as they are meant for using Exchange Web Services (EWS) SOAP APIs.
If someone is looking for the solution, it was a problem of service principal.
We were pointing to the wrong Service Principal and that was the cause of the issues with permissions.