I am trying to build a bot that will need a basic outlook login. I was watching this video
https://channel9.msdn.com/events/Build/2017/P4063?term=cortana%20skill
and the guy at 17:02 adds the following values for scopes and Authorization and Token URLs:
wl.basic wl.birthday
https://login.live.com/oauth20_authorize.srf
https://login.live.com/oauth20_token.srf
then I stumbled across Microsoft's documentation:
https://learn.microsoft.com/en-us/cortana/tutorials/bot-skills/bot-skill-auth
where it says that the values for the scopes and URLs are:
User.Read offline_access openid
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
The video is from May 10, 2017 (which was the BUILD 2017), and the article is from April 08, 2017. So which one is correct/deprecated? Also I tried to mix them and this is what the Login prompt looks like with the different combinations:
As you can see all four variations of scopes/urls produce totally different sign in UI?!?!?! (and the ones at the right column also look slightly broken) Which is the correct way?
UPDATE
Also, following the article I added a singin card to my bot with the URL described in the documentation:
var message = context.MakeMessage() as IMessageActivity;
message.Speak = "This is a Sign-in card";
message.Summary = "This is a Sign-in card";
message.Text = "Message Text";
message.Attachments = new List<Attachment>(){
new SigninCard("You need to authorize me", new List<CardAction>()
{
new CardAction()
{
Value = "https://login.microsoftonline.com/?redirect_uri=http%3a%2f%2fbing.com%2fagents%2foauth",
Type = "signin",
Title = "Connect"
}
}).ToAttachment()
};
await context.PostAsync(message);
and to my surprise clicking the sign in button, an entirely new login UI, resembling Office 365 pops up:
UPDATE 2 FRESH!!!:
https://twitter.com/chriscapossela/status/888029356504645632
This answer requires a little bit of history :)
Back in the day, in order to authenticate Microsoft users, you had to know if the user had an OrgId (used to log into Microsoft's business services) or MSA (used to log into non-business Microsoft services) identity. For reasons I won't digress on, it resulted in two oAuth endpoints:
https://login.live.com/... is/was the token endpoint for MSA-specific identities
https://login.windows.net/[AAD-TENANT-ID]/... is/was the token endpoint for OrgID-specific identities
Understandably, developers got very upset about this. To solve this issue, Microsoft created the v2 app model, which allows you to use one AuthN/Z endpoint for both account types. The v2 app model does a lot of black magic to abstract away differences in consent, scopes, endpoints, etc between MSA and OrgID, so you as a developer don't have to worry about it.
However - some of our APIs, especially those created pre-v2 endpoint, are geared for a specific account type. The Live APIs, which Nafis uses in the Build demo, IIRC don't play well with OrgID identities - if the user logged into the v2 endpoint with their OrgId account, you'd get non-ideal behavior since the access token would be for an OrgID account. To prevent this skill-breaking behavior, he uses the MSA endpoint (live.com) directly, preventing OrgID users from logging in to the skill at all.
You're seeing the different UX when mixing URLs because the v1 and v2 endpoints provide different login UX. The error message in the last image seems to indicate that you're using a MSA identity to log into a converged API. $5 says that's related to the fact that you're mixing v1 and v2 endpoints/scopes/etc, but it's hard to tell without looking at the exact API call.
The CSK docs use the v2 endpoint because most of our APIs (including the mail/Outlook APIs, which are now part of the Microsoft Graph) use it these days. When I'm writing code utilizing MSFT services (or when I'm writing documentation for the services ;)), I default to the v2 app model unless the API docs specifically mention v1 endpoints, like the live API docs do.
The Firebase Web-App guide states I should put the given apiKey in my Html to initialize Firebase:
// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>
By doing so, the apiKey is exposed to every visitor.
What is the purpose of that key and is it really meant to be public?
The apiKey in this configuration snippet just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project. This same configuration data is also included in every iOS and Android app that uses Firebase as its backend.
In that sense it is very similar to the database URL that identifies the back-end database associated with your project in the same snippet: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.
If you want to learn how to secure all data access to your Firebase backend services is authorized, read up on the documentation on Firebase security rules. These rules control access to file storage and database access, and are enforced on the Firebase servers. So no matter if it's your code, or somebody else's code that uses you configuration data, it can only do what the security rules allow it to do.
For another explanation of what Firebase uses these values for, and for which of them you can set quotas, see the Firebase documentation on using and managing API keys.
If you'd like to reduce the risk of committing this configuration data to version control, consider using the SDK auto-configuration of Firebase Hosting. While the keys will still end up in the browser in the same format, they won't be hard-coded into your code anymore with that.
Update (May 2021): Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to the backend services in your Firebase project to only those coming from iOS, Android and Web apps that are registered in that specific project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access, while still allowing direct access to the database from your client-side application code.
Building on the answers of prufrofro and Frank van Puffelen here, I put together this setup that doesn't prevent scraping, but can make it slightly harder to use your API key.
Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:
firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});
Only the database security rules can protect your data.
Nevertheless, I restricted my production API key use to my domain name like this:
https://console.developers.google.com/apis
Select your Firebase project
Credentials
Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"
In "Accept requests from these
HTTP referrers (web sites)", add the URL of your app (exemple: projectname.firebaseapp.com/* )
Now the app will only work on this specific domain name. So I created another API Key that will be private for localhost developement.
Click Create credentials > API Key
By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.
In order to make sure I don't publish the wrong API key by mistake, I use one of the following methods to automatically use the more restricted one in production.
Setup for Create-React-App
In /env.development:
REACT_APP_API_KEY=###dev-key###
In /env.production:
REACT_APP_API_KEY=###public-key###
In /src/index.js
const firebaseConfig = {
apiKey: process.env.REACT_APP_API_KEY,
// ...
};
I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.
You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.
I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.
I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.
The API key exposure creates a vulnerability when user/password sign up is enabled. There is an open API endpoint that takes the API key and allows anyone to create a new user account. They then can use this new account to log in to your Firebase Auth protected app or use the SDK to auth with user/pass and run queries.
I've reported this to Google but they say it's working as intended.
If you can't disable user/password accounts you should do the following:
Create a cloud function to auto disable new users onCreate and create a new DB entry to manage their access.
Ex: MyUsers/{userId}/Access: 0
exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);
Update your rules to only allow reads for users with access > 1.
On the off chance the listener function doesn't disable the account fast enough then the read rules will prevent them from reading any data.
I believe once database rules are written accurately, it will be enough to protect your data. Moreover, there are guidelines that one can follow to structure your database accordingly. For example, making a UID node under users, and putting all under information under it. After that, you will need to implement a simple database rule as below
"rules": {
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
".write": "auth != null && auth.uid == $uid"
}
}
}
}
No other user will be able to read other users' data, moreover, domain policy will restrict requests coming from other domains.
One can read more about it on
Firebase Security rules
While the original question was answered (that the api key can be exposed - the protection of the data must be set from the DB rulles), I was also looking for a solution to restrict the access to specific parts of the DB.
So after reading this and some personal research about the possibilities, I came up with a slightly different approach to restrict data usage for unauthorised users:
I save my users in my DB too, under the same uid (and save the profile data in there). So i just set the db rules like this:
".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"
This way only a previous saved user can add new users in the DB so there is no way anyone without an account can do operations on DB.
Also adding new users is posible only if the user has a special role and edit only by admin or by that user itself (something like this):
"userdata": {
"$userId": {
".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
...
EXPOSURE OF API KEYS ISN'T A SECURITY RISK BUT ANYONE CAN PUT YOUR CREDENTIALS ON THEIR SITE.
Open api keys leads to attacks that can use a lot resources at firebase that will definitely cost your hard money.
You can always restrict you firebase project keys to domains / IP's.
https://console.cloud.google.com/apis/credentials/key
select your project Id and key and restrict it to Your Android/iOs/web App.
It is oky to include them, and special care is required only for Firebase ML or when using Firebase Authentication
API keys for Firebase are different from typical API keys:
Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; that can only be done with Firebase Security Rules. Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files.
Although API keys for Firebase services are safe to include in code, there are a few specific cases when you should enforce limits for your API key; for example, if you're using Firebase ML or using Firebase Authentication with the email/password sign-in method. Learn more about these cases later on this page.
For more informations, check the offical docs
I am making a blog website on github pages. I got an idea to embbed comments in the end of every blog page. I understand how firebase get and gives you data.
I have tested many times with project and even using console. I am totally disagree the saying vlit is vulnerable.
Believe me there is no issue of showing your api key publically if you have followed privacy steps recommend by firebase.
Go to https://console.developers.google.com/apis
and perfrom a security steup.
You should not expose this info. in public, specially api keys.
It may lead to a privacy leak.
Before making the website public you should hide it. You can do it in 2 or more ways
Complex coding/hiding
Simply put firebase SDK codes at bottom of your website or app thus firebase automatically does all works. you don't need to put API keys anywhere
I have an app with a lot of users. I have now with an update decided I wanted to ask for their email. I am using Azure Mobile App Service, with microsoft authentication. Therefore I added the wl.basic and wl.emails.
I then read I could access the email by using:
var claimsPrincipal = User as ClaimsPrincipal;
string email = claimsPrincipal.FindFirst(ClaimTypes.Email).Value;
I however never got to try the above because I ran into another issue. I store the users data by the NameIdentifier from:
var claimsPrincipal = User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
The issue is that the sid is changing when I add more scopes to the login. My issue is therefore is there some way I can extract an identifier that goes across this ?
This is a known issue. See this wiki post for more information about how to get stable identifiers for your users.
https://github.com/Azure/azure-mobile-apps-net-server/wiki/Understanding-User-Ids
Here is a snippet from the page which introduces the problem:
When App Service Authentication was first released, the sid was generated based on the email of the user. This made it great for linking a user across two providers if they used the same email for google, facebook and twitter, but it meant that the sid was not stable. Someone could change their registered Facebook email and suddenly the sid would be different. This is why this wiki page was written -- to show how you could generate your own stable user ids.
The page goes on to explain how to get the stable identifiers and the options you have for doing this kind of migration.
How can I get a user's full name from Google when authenticating with yesod-auth's GoogleEmail backend? In my app, I'd like to require users enter as little redundant information as possible.
I'm not sure where to start. Will I need to modify yesod-auth?
Unfortunately, yesod-auth doesn't currently provide you with enough access to the underlying OpenID response to get that information. I'd be happy to accept a pull request to extend the API in that direction.
I want to get access token foursquare like this link `https://developer.foursquare.com/overview/auth#userless' and this is code
https://foursquare.com/oauth2/access_token
?client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&grant_type=authorization_code
&redirect_uri=YOUR_REGISTERED_REDIRECT_URI
&code=CODE
I don't understand what YOUR_CLIENT_ID,YOUR_CLIENT_SECRET and YOUR_REGISTERED_REDIRECT_URI are. Can you explain and show some examples ? Thank you very much for helping.
"Before you get started, you should create an app on Foursquare. This will give you a client ID and client secret which are needed for using the API. The documentation in this guide is meant to give a high-level conceptual overview of the Foursquare platform, help you grok its different parts and capabilities, and get started using the API’s most popular features."
https://developer.foursquare.com/start
Go to the link: https://foursquare.com/developers/apps
Click the option: "Create a new app". Enter the name of the app and a valid url from where your app can be downloaded. These two fields are mandatory. You can provide the details for other fields also. If you don't have a download link, you can create a folder in dropbox (google drive, onedrive) and provide that link. Create your app and you will get your private CLIENT_ID and CLIENT_SECRET.