I know there are several ways to access Firebase Authentication, but if I use the Firebase Auth REST API and the Firebase Authentication Unity SDK, are they both secure? What is the security of the REST API and the Firebase Authentication Unity SDK? Is one more secure than the other?
The short and simple answer is obviously yes, they are both really secure.
Firebase Auth is maintained by Google and used in very large projects. OAuth with SSL is quite secure and I can assure you it's more secure than almost anything you could write on your own.
It's very hard to answer to "it's one more secure that the other", this question is really vague and hard to find a definitive answer. If your client-side is compromised or you do not enforce good enough server-side security rules and checks of course it does not matter how secure their APIs really are.
Related
Currently, I am doing research on my Internship company. The company uses the OAuth2 method to do Integration between the company web app services and the partner's API, but it's not support knowing who the user is. Also, I found an issue that the company put the refresh token and access token in session storage on web browser. As far my research, the web application can be attacked using the Hijacking method.
The other thing is some of the integration only use API key to do handshakes.
My Hypothesis :
The company needs to implement OIDC before the OAuth2
The Refresh and Access token on session storage need to be encrypted, but I don't know it is possible or not
The company who only using API key need to implement OAuth2
my question :
is the OAuth2 method the best method secure an Authentication?
it is possible to encrypt token on session storage web browser?
Thanks in advance :D
Short answer: Yes
Your Hypothesis
OIDC is based on oAuth2 its an Authentication flow and itself has tokens
StackOverflow question
OIDC WebSite
OAuth2 is based entirely on HTTP requests, you can get the tokens and encrypt them with whatever encryption algorithms you want.
OAuth2 is not mandatory for APIs, if you already secure your APIs with keys (I don't know the security level and how these keys are created) you can only use them.
Question's answers
OAuth2 is one of the authorization and authentication methods, there are many, and it's not a "One size fits all" solution.
Of course! the token is a base64 string, you can use a Crypto library
Final considerations
I suggest you read about OAuth2 and try some flows, below are some resources where you can play and learn OAuth2
OAuth2 Docs
OAuth2 Playground
I would like to know if there exists alternative for OpenID/Oauth2.0 for first-party apps like public SPA without redirecting user to OpenID login page?
I know there exists password grant type, but it's deprecated as written in Oauth2.0 docs.
And if there is no alterative solution, is it good choice to implement only JWT issuer(auth) service without OpenID on my own? Will it be still secure? If yes, then which details should I take into consideration?
If you have a first-party app, which only talks to your backend then it should be enough to use sessions. You don't need to implement OAuth and JWTs, and using sessions will solve some you some security issues with tokens (e.g. how to securely store them in the browser).
If you do decide to use access tokens I highly recommend implementing OAuth or OIDC, as this will mitigate some common security vulnerabilities.
I'm working on a new SPA with a GraphQL backend. What I'm not sure about is how to properly solve authentication between the JS client and GraphQL backend. For the purpose of authentication it doesn't really matter if the backend is GraphQL or good old REST.
I read some articles and other questions here on StackOverflow. Here are the possible solutions I gathered and their problems:
Cookies
Well of course cookies are vulnerable to CSRF attacks. So maybe cookies could be used with some additional CSRF protection. I couldn't find how to implement it in this case though. How to create and use CSRF tokens in a SPA?
JWTs (JSON Web Tokens)
Apparently JWTs have many problems and should not be used:
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
Some other tokens
This is what most REST APIs do - the client sends an authentication token usually in a X-Auth-Token header. This of course doesn't have the CSRF vulnerability of cookies but is not entirely suitable for SPA (REST APIs were usually not designed for SPA frontend applications). It shares some of the problems with JWTs - mainly that the token needs to be stored in a LocalStorage on the client side. (Explained in the article about JWTs linked above.)
The problem is that I always found just some critique why solution X is wrong with no information what to use instead or with a recommendation to use solution Y with no regard to the problems of that solution.
Many websites are saying that the API should be stateless - not saving any data about currently authenticated sessions because it prevents horizontal scaling. I don't really share this concern - 99% of applications don't need horizontal scaling anyway.
So what is the best practice for SPA authentication? What solution are you using in your SPAs?
I'm not necessarily disregarding all the solutions listed above but if any of them should be used I need to solve their problems somehow or have a very good reason to disregard the problems.
When it comes to authentication, there are a lot of really smart but angry people fight against pretty much any concept ever, and you're right, often they forget the part where they should recommend an alternative.
OAuth 2 has been crapped on by a lot of people, but it is indeed absolutely fantastic, so long as you use SSL!
There's a whole chapter explaining the pros and cons of all the authentication types one of my books: Build APIs You Won't Hate
I consider to use OAuth for Single Sign-On (SSO) with RESTful services. At first sight to use OAuth as the de facto standard looked naturally to me. But I must confess that I don't understand how to use it for SSO. During studying OAuth I discovered more and more criticism of Authorization - so much that I tend to think OAuth has failed.
OAuth is hard to implement.
Usability is poor.
Why Facebook doesn't implement OAuth today:
"OAuth is more complex and less performant than our own native authentication mechanism"
"OAuth WRAP looks like it will solve most or all of these problems"
Bad performance because of two many requests and long URIs
"Library quality is overall pretty poor"
Possibly WRAP, powered by Microsoft, Yahoo and Google, is going to replace OAuth.
What's going on with OAuth (and WRAP)?
So has OAuth failed? What are the alternatives for SSO - preferably those with wide acceptance or the perspective to become widely used? Would you prefer WRAP?
OAuth isn't a SSO solution, it's a protocol commonly used for delegated API authorization. 3 legged OAuth allows a client requesting access to a protected resource to delegate authorization to the server hosting that resource. Basically, the user doesn't have to give their credentials to a 3rd party (the client), only to the server hosting the protected resource. OpenID may be a more appropriate solution if you are looking to implement single sign-on. You can also use OpenID OAuth extension which will allow you to combine authentication with authorization via OAuth.
Work is currently being done on OAuth 2.0. WRAP was developed as a stop-gap solution to address some use cases not covered by the original OAuth 1.0a spec. WRAP will not replace OAuth, rather ideas from WRAP will make their way into OAuth 2.0 where appropriate. A number of the original authors of OAuth, as well as one of the authors of WRAP have written about this here:
What's going on with OAuth?
So no, OAuth hasn't failed, in fact it's enjoyed pretty wide adoption. OAuth 1.0 will continue to be implemented by a large number of providers and eventually OAuth 2.0 will be available as well. WRAP is there for people who want to take advantage of the use cases it addresses now.
With regard to the difficulty of implementing OAuth as a client, why not try it out? The available libraries are of varying quality, but with a decent one you can usually implement an OAuth client in under a day.
I have been investigating OAuth to share resources in my site to other sites.
But, hole of OAuth specification was reported several days ago.
http://oauth.net/advisories/2009-1
Many sites decided to stop OAuth until fixed version is released.
Currently, can we have any alternative to OAuth?
I want an open-standard and secure authorization protocol.
OAuth was built because there weren't any existing standards that solved the same problem. A fixed OAuth spec is forthcoming soon. It will be a pretty small change to the existing protocol.
In the short term, your best bet is to fall back on basic authentication mechanisms (requiring users to enter their credentials into your site for the foreign site).
Like Jonathan said, the hole will be fixed soon in the spec.
Oz is a web authorization protocol based on industry best practices. Oz combines the Hawk authentication protocol with the Iron encryption protocol to provide a simple to use and secure solution for granting and authenticating third-party access to an API on behalf of a user or an application.
OZ github link
Oz builds on the well-understood concepts behind the OAuth protocol. While the terminology has been updated to reflect the common terms used today when building applications with third-party access, the overall architecture is the same.
There was a revised version of the OAuth 1.0 spec, but since this question was asked OAuth version 2.0 is getting stable, and would often be the reccomended protocol.
OAuth version 2.O is a bit complex protocol compared to its predecessor, but more secure. It is specially tailored to address the security concerns of enterprises. Currently Facebook and Google authentication flows are based on OAuth 2.0
Oauth has come up with new OAuth 2.0 standard which is much more secure than OAuth 1.0 and 1.0a.It scaps access token and access secret and introduced access token and refresh token.Access token in Oauth 2.0 is validate for certain timeframe,after that it is regenrated or refreshed using refresh token.