I'm writing a web app that is very tied to a different app (Twitch), so my plan is to only offer logging in through them. I'm trying to come up with an auth scheme for my app, and am thinking about implementing it by just packaging up the OAuth2 creds I get from Twitch, and setting that as a JWT cookie. See diagram of auth design
I'm having a hard time finding another example of someone doing or suggesting this, so I get the feeling I'm missing some reason why this is a bad idea, but I can't figure out why. The cookie is a JWT so it's signed, and since the tokens are all from Twitch they can be revoked on their end if necessary. And since all the Twitch creds I need are in a cookie, I don't need to store any access tokens in my DB.
So am I missing something that makes this a bad idea, or is this a secure enough solution to use?
This is a really interesting question. Sadly the answer to this is "it depends", based on the risk / reward to your app and business. Let me try to clarify that to help.
Let's assume that in your system authentication is core to the service. So essentially if your users cannot authenticate then they are not able to access the system.
Using a third party to provide authentication has many pro's and con's. Obviously the pro's are around not having to manage credentials, password resets, attempted attacks on the credentials etc. Also, there are advantages to the customer of not having another set of credentials to manage.
The con's largely are around the dependancy on the third party, if Twitch goes down then no-one can use your system. (This might be true anyway, based on your description).
Essentially, what I recommend is that you weigh up the pro's and con's in your environment. Assuming that the pro's outweigh the con's then using OAuth2 is a great way of authenticating.
While I don't have an example to hand of a website using only 3rd party auth I do believe the industry is getting there. Many sites have 3rd party auth at the top of their sign in options showing a preference over creating a new set of credentials. You don't have to look much further than StackOverflow that has the following order:
Google
GitHub
Facebook
StackOverflow account
Related
In short: In GCP credentials can be restricted with application restriction and with API restriction, but Identity Toolkit API cannot be restricted on Expo mobile application.
-In web both restrictions work
-On android/iOS API restriction works but (as I have tested, correct me if I'm wrong) application restrictions does not
Now if using email/password authentication there is an issue.
There is a huge insecurity here as if anyone gets to know your API key (you define in initializeApp and so you connect to Firebase with and so use with Identity Toolkit API).
They can only by knowing that key call Firebase Auth REST API "Sign up with email / password" from anywhere and create users for your project!!
Am I wrong, missing something or can this be prevented somehow?
Things you can do to prevent this:
In "GCP>credentials>Identity Toolkit API" you can lower "Queries per minute" and "Queries per minute per user"
You can in "Firebase>Authentiction>Sign-in method>Manage sign-up quota" lower the quota from same IP address to minium (but does this help in case of android/iOS application?)
But there is no completely secure solution unless you can application restrict your API key as far as I know.
I got the following answer from Firebase support and since there has not been answers I will add this as correct answer for anyone looking solution for same thing or seeing this question.
First of all, I would like to thank you for choosing Firebase to
implement your application. I know that these kinds of situations
could be frustrating, let's work together to provide the best solution
for you.
I have checked your case and I would recommend that you reinforce your
Security Rules, because this is not a security risk, as long as you
secure access to the data within your project correctly for your
requirements, as it is mentioned in this external entry.
We don’t have a way to know the origin of those emails, even if they
were created by real users through your app, but if you identify fake
accounts you can use Cloud Functions to delete all emails registered
with that pattern using Auth triggers. Alternatively, you can delete
the accounts after an established time without activity using Schedule
Functions.
Additionally, if you don’t want to have users on your application, you
would probably need to use the Admin SDK and authenticate the
application by service account instead.
While testing the security of one of our product, a web application, using the REST API of Firebase we got surprised when we realised that refresh-tokens never expire in the V3 of the Firebase implementation, allowing any refresh-token to create new tokens forever.
While local-storage seem a reasonably safe solution today, we are concerned by the possibility that it could fail tomorrow, even for a short amount of time, and that we cannot stop someone from using any of these refresh-tokens.
Two factor authentication will help mitigate the issue, but the first step would become compromised nonetheless.
Is there a way to blacklist tokens, or similar behaviour, with Firebase, without handling all tokens exchange, such as minting, ourselves? We could not find such feature when going through the doc.
Any advice appreciated.
Authentication sessions don't expire with Firebase login. But the ID token will have to be refreshed hourly, to keep access to the services. If you disable an account, refreshing the token will fail and the account won't be able to access services anymore. There is no way to invalidate individual tokens.
Firebase recently implemented revokeRefreshTokens() inside the admin sdk. Although this will not let you kill an invalid JWT, it does allow you to prevent a refresh of the token (from my testing so far at least) and it allows cleaner control flow inside firebase database.
See Admin Manage Sessions For rough examples
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
I have two asp.net projects at the different domains. These projects use one database.
Let say www.test1.com and www.test2.com. (Late will be more projects)
I already have registration form and registered users.
Now I need to implement SSO possibility without registration at the external sites (google, openId, facebook).
All implementation which I have found required external registration (CAS, Federation, Facebook, openId).
Also I have read this article http://www.codeproject.com/KB/aspnet/CrossDomainSSOExample.aspx, but as far as I understood from comments such solution very insecure.
Please suggest solution or existed library which can help me to use SSO without external registration.
I needed the exact same solution for a client I was working for, I did the research and the only good solutions that I found where either too complex and not well documented or too expensive (I forgot which companies I looked into). So I decided to build a custom solution.
This is a short summary of the solution implemented:
In order to make things more clear let's call "nodes" the domains where you wanted to authenticate a user, and "SSO" the provider of the authentication.
I used a solution that is similar to the one in the link you posted HOWEVER I used the Asp.Net security cookie whenever I wanted to authenticate a node, and also to authenticate the SSO website:
HttpCookie formsCookie = FormsAuthentication.GetAuthCookie(userName, false, HttpRuntime.AppDomainAppVirtualPath);
HttpContext.Current.Response.Cookies.Add(formsCookie);
This also allowed me to not have to query back the SSO provider for each web request as the example you posted seem to do.
I used a new AuthenticationKey for each time I wanted to communicate from the SSO provider back to the node that the authentication was successfull.
Also I added some security features like encrypted communication and that the key could only be valid a max of 2 seconds (the time for the SSO to pass it to the node) and as soon as it was used it would be deleted.
I believe this solution is safe enough, however using an external ready made solution is surely safer.
It took me only a few days to implement the whole solution, so it's not too long of a task. However I cannot share the project as I am not sure the client would agree.
I hope those suggestions might help you.
Let us know what you decide to do in the end.
I would like to create a secure login page for a pre-defined set of users (so no creating username/passwords by the users themselves). I've looked up a few sites and they all seem to suggest using Microsoft's Membership or something. I am not very sure as to why that's used, but all you need to know is that I will be creating the login details. I just need to make the login secure, ie, no duplicate logins, no logins from different browsers and cookies and sessions and encryption and all that. Any one have the code/links to where I can get all this? Thanks in advance.
You have a couple of options here.
Case 1 :
Role your own security but bear in mind you will oversee something. Security isn't easy and its sooo easy to overlook something. Hashing , salting , encryption etc...
Case 2:
If its a simple site just use Microsoft memberschipprovider. It is good and they spend 3 years tweaking / patching it. You can also override the memberschipServiceprovider to implement some additional security. or to tell the memberschipprovider what data should be used.
Optional:
Extend your ISS server with this open-source firewall : http://www.aqtronix.com/?PageID=99
It provides some cool features for "free"(If you have access to install it).
The best security is when you find the balance between secure and accessible vs Top-security and inaccessible.
And to answer the link part of your question:
http://www.owasp.org/index.php/Main_Page
If you want more information on microsofts' memberschipprovider :
Google :) or Bing or yahooooo!
Goodluck