More of a theoretical question here - how can you get around using OAuth when you don't want to use it, but are using an API that requires it.
For example recently I was looking through the Bing Ads API and noticed they now require you to do OAuth as part of the process. Which makes sense if you're making an application that allows a user to control their Bing Ads account via your app. However, let's say you wanted all of your users to interact with one Bing Ads account.
Is it possible to hardcode all of the OAuth pieces in the background and just use the same authentication for every user to essentially send their stuff to the same Bing Ads account.
- If so, what sort of negative impacts would there be on that?
While it is simply not possible to get around using OAuth if the API requires it, OAuth can be used for more than just the "access delegated to client by current user" use case. As you suggest, if you want all users of your app to interact with your Bing account ("on your behalf" on OAuth speak), you can certainly do that with OAuth.
For an OAuth 2.0 implementation this would mean that you obtain an access token and preferably a refresh token in some way for your app, e.g. by you yourself going once through the Authorization Code flow (also, some services allow you to generate tokens in their web UI). Then you would "hard-configure" the token(s) in your app and use it/them to talk to the Bing API.
If a refresh token is included as well as an access token then your app can get a new access token in the backend whenever the old one expires without you (or your users) having to go through that initial flow again.
Be aware that this is not good practice for mobile apps, where you would have to distribute your app with the tokens embedded in the binary packages. Those tokens could easily be grabbed through hacking/scanning those binaries. But when the tokens are used in a backend service and never exposed in the front end, this is a perfectly valid scenario.
Related
I have a mobile app using Azure AD B2C which works fine. I can create an account, login, forgot password etc. That's all fine.
The mobile app stores data on the device.
The mobile app should also be able to push data to a remote database and trigger various functions via a .net core web api.
The mobile app should only be able to do that if it authorises itself successfully with the api using the credentials, or access tokens, it has from the login.
I assumed that this could be implemented easily (because, why couldn't it be?)
But now, after weeks of searching, hours of video-watching, 10's of aborted [test] projects, & 1000's of user accounts; I'm not sure whether the thing I want to do is a thing that can be done or should be done.
Thoughts?
Yes, this is of course possible :)
You can check the code samples for some examples of how to do it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/code-samples.
Your mobile app can acquire an access token for itself.
You'll have to define in B2C that your app contains an API, and then define the app ID URI (an identifier for the API, not a URL).
You can then define scopes that API exposes.
These can be different permissions that applications calling the API can have.
In your mobile app you then acquire an access token using those scopes.
This token can then be passed to HTTP requests to your API, which the API has to authenticate.
Do ask if you want to know about something specific.
After reading the documents of Google API. I know that if a project we create needs to access private data, we should use oauth. But here is my situation. we will open a business account in Youtube, and we will create a project to push videos to our own account, we don't need to operate other user's' account. Can we use google youtube data api without OAuth?
There are two ways to access private user data with Google APIs.
Strait Oauth2. where you have a consent for asking the owner of the account if you can access it
Service accounts which are technically pre authorized by the developer.
Normally I would say because you are only accessing the one account that you own, use a service account. Unfortunately the YouTube API does not support service account authentication.
Due to the lack of service account support you will have to use Oauth2. I have done this in the past.
Authentication your script once, using a server sided language of some kind. The Authentication server will return to you a Refresh token. Refresh tokens can be used at any time to get a new access token. Access tokens are used to access Google APIs and are only valid for an hour. Save this refresh token someplace. You will then be able to allow access the YouTube account in question when ever you like.
Note: You will have to watch it. Refresh tokens can on rare occasion become invalid. I recommend having a script ready that will allow you to re authenticate the application again storing a new refresh token. Its rare that it happens but it can happen best to be pre-paired.
Oauth Play ground
Part of the point of Oauth is that it identifies your application to Google though the creation of your project on Google developer console. Things like quota and access to which APIs is controlled though that. If you spam the API they will know and shut you down. (never seen this happen)
When you request access of a user it pops up with the name of the project on google developer console. This is identified by the client id and client secrete for that project on google developer console. When I use oauth playground I get asked 'Google OAuth 2.0 Playground would like to ..'
So by using playground you are using Googles client id and client secrete to create a refresh token for yourself. If N other devs are also doing this the quota for YouTube may be used up in the course of a day. Also security wise you are now giving that project access to your data. Ignore that for a second what if google suddenly decides to remove change the client id or generate a new one. Your refresh token will no longer work. What if random dev X is using it as well and he starts spamming everything and the client id gets shut down (Think this happened last year) your going to have to wait for google to upload a new client id for the one that has now been banned.
Google OAuth 2.0 Playground might seam nice but its not for daily use IMO its good for testing nothing more. Create your own project and get your own access its not hard just requires a programing language that can handle a http Post.
My tutorial Google 3 legged oauth2 flow
Currently we are not using OAuth with our apps but we are working on making the shift, we have direct login and capture the user/pass that was entered and store those. We then turn around and use the stored credentials for a feature that allows the user to open a record within Salesforce.com, we pass the user/pass in to the login endpoint along with a starting URL to the specific record, this works great and is a well liked feature as it is a simple SSO from the App to Salesforce.com where the user can see all data that may not be visible within the app.
Moving to OAuth 2.0 and using the standard webflow, we no longer can capture the user/pass, which is actually a good thing as far as security is concerned. We would however like to keep this functionality, is there anyway of SSO'ing into Salesforce.com by passing along one of the OAuth tokens or some kind of sesson id?
After reading more and thinking about what OAuth accomplishes I feel like this probably isn't possible being that the tokens obtained are meant to be used only with the API and not with the front end system. I hope that I am wrong though and there is a way to login to the front end using these tokens.
EDIT
Ok I am editing to hopefully make this more clear. Currently user's authenticate using the login() API method with their user/pass, we store this user/pass locally (not ideal). We then sync a subset of data that the users can access anytime within the app, being that it is a subset, we have a feature to "SSO" to the Salesforce.com front-end. This simply opens Salesforce.com in a web-view (UIWebView) using the URL https://ns8.salesforce.com/?pw=PASSWORD&un=username#example.com&startURL=/recordId. This will log us in to Salesforce.com and open the specified record.
Moving forward we want to use OAuth 2.0 with the web flow so that we aren't handling the user/pass and so that we do not have to deal with Security Tokens or opening specific IP ranges to allow login without a Security Token.
With that said, is there anyway to use the tokens/credentials received from the OAuth authentication to open Salesforce.com, automatically log the user in, and goto a specific record?
I may have mis-used "single sign on" before, but in a sense, this simulates an SSO from our App to Salesforce.com, in that our users can touch a single button within the app and be logged in to the Salesforce.com web interface.
When you request an OAuth token, you can specify what scope it has, options include api only (the original type of tokens), or other options which include the ability to use the token with the UI pages. (see the scope parameter detail in the help). One of the still missing peices is a way to bootstrap the UI with that token when all you can do is tell a browser/webview to goto a URL, but a widely used (but unsupported) way is via frontdoor.jsp, e.g. you'd open https://{instance}/secur/frontdoor.jsp?sid={the_Access_token}&retURL={optional_relative_url_to_open} remember to URLEncode the 2 values.
So I think you are saying your application uses the SFDC username and password to just authenticate to retrieve a record from SFDC to display in your app?
IF this is correct - which I think it is - then you could just use the standard Salesforce Single Sign On system to authenticate. There is a guide here which outlines the process of setting up a SAML SSO system with Pat Patterson writing an interesting feature on how the security system works here. He has also written a great blog post on DeveloperForce here about the nitty details of OAuth in general for Force.com and not just the SAML setup. I have used the OAuth system in an iPad app against SFDC and it works quickly and easily. I can't see why your system should be unable to use the protocol as you desire.
Direct access into Salesforce is a key benefit of SSO and definitely provided. I'm not sure where you read that SSO in Salesforce is API only. From the SSO PDF pbattisson linked for you:
With single sign-on, users only need to memorize a single password to
access both network resources or external applications and Salesforce.
When accessing Salesforce from inside the corporate network, users are
logged in seamlessly, without being prompted to enter a username or
password. When accessing Salesforce from outside the corporate
network, users' corporate network login works to log them in. With
fewer passwords to manage, system administrators receive fewer
requests to reset forgotten passwords.
OAuth 1 & 2 are both supported, though I'm a fan of OAuth 2 since 1 has really finicky additional steps involving the order of parameters and their encoding sequences. I recently wrote an Apex-Twitter integration and quickly realized it wasn't going to be as easy as Facebook, which uses OAuth 2.0.
But in your case it sounds like you just want to provide users with the ability to actually login to Salesforce and go to a specific landing page once authenticated. This is definitely doable.
Good luck!
I have my OAuth process working well, I have an application that requires Google Adwords and Google Analytics access tokens. For whatever reason, Google has made these separate in terms of acquiring OAuth tokens. I know there is limited capability of using the Analytics tokens to access an Adwords account, but this requires the user to actively connect their two accounts, and even then access is limited. I have the user redirected away to authenticate with Google and when they come back I have their token and token secret.
One main functionality I need to impose is the user must be able to authenticate one account, and just use that. Or authenticate both accounts (analytics and adwords) and be able to use the two in tandem, with the tokens stored separately.
My main question is this: how can I figure out which oauth token has been returned? Currently, I have the oauth process located on two separate pages (two seperate callback urls, one for analytics and one for adwords), but I want to make them on the same page, and I've realized that they both return oauth_token & oauth_token_secret. Has anybody come across this before? How did you decipher between the two when the callbacks are located on the same page?
What's the best practice for this situation? It's not the end of the world, if I have to authenticate the user for each service on two separate pages, but would like to know that I have tried to implement something like this :)
Thanks!
Generally you should have a separate callback page for each service. It's simpler and easier to keep the tokens separate.
I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.
Where I'm confused if is it useful in a server web application? I don't want any user interaction.
But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.
What is the correct workflow for my case?
Storing the request token or access token in config file?
Or the easist way, using HTTP basic authentication?
Thanks
If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.
In this case there are 2 main factors to consider.
1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth.
2) Do you want to put in the extra effort to implement OAuth.
If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.
Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?
If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.