I've recently started working on a game project for mobiles for which I want to maintain user accounts.
Instead of writing my own user accounts layer, I thought I'd allow people to authenticate with Google/Facebook/Twitter etc. accounts. Examining the delegated authentication schemes supported by each of these providers like OAuth/OpenID, it seems like there must be a browser for logging in any of the providers. Can anyone suggest workarounds or straightforward ways to authenticate without having to open a browser.
If that's not possible, how are applications like Google Talk logging in without opening a browser?
The browser is simply speaking HTTP (over TCP). You can create an ASP.NET web service or a WCF web service which also speaks HTTP, which will follow the same sequence of HTTP actions.
Related
I'd like to add the ability to create JIRA issues from within a Unity game (C#), such as for submitting player feedback and bugs. I see various authentication approaches, from "basic" auth (just a raw UN and PW) to an Auth Token approach, to possibly some OAuth-based approach which I don't yet understand.
I've set up JIRA integration in web projects over the years, and it was fairly simple. I never had concerns over authentication, since the credentials to access JIRA were always stored within the web server's configuration. But with a deployed application (such as a game created in Unity), I don't understand if there's any secure/correct way to provide credentials to the application. It seems that it would be trivial for anyone to either inspect the code, or the memory of the running application, and extra the authorization credentials.
Is there a secure way for a desktop application (not connected to a central server) to authenticate against an API like JIRA's?
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Updated based on questions from #user18044 below
If a user is authenticated in two different web applications via 2 different SAML-based identity providers, and one of the applications needs to request data from a web API exposed by the other application, would it be possible to call the web API methods securely by virtue of the user's current authenticated status in both applications without separately securing the API methods via an API level authentication protocol such as OAUTH? Note that both applications are owned and operated by my company and share the same 2nd level domains and user base, even though the identity servers are different (one is legacy).
Some further information: Application A is a portal application that is going to host widgets using data supplied from Application B. Application A will only communicate with application B via a web API exposed by application B. Currently application B does not expose a web API (except internally to the application itself). This is new functionality that will need to be added to application B. Application A will use Okta as its SSO. Our lead architect's proposal is to continue to use a custom legacy IDP server that we developed internally based around using the dk.nita.saml20 DLL. They are both SAML based I believe, but I don't think they could share the same identity token without some retrofitting. But this is hitting the limits of my knowledge on the topic of authentication. :) I think our architect's plan was to have the user authenticate separately using the two different identity providers and then only secure the web API using CORS, his reasoning being that since the user is already known and authenticated to use application B, that there wouldn't be any security implications in allowing application A to call application B's web api methods, as the user should be authenticated in application B. This seems quirky to me, in that I can imagine a lot of browser redirects happening that might not be transparent to the user, but other than that, I'm just trying to figure out where the security holes might lie, because it feels to me that there would be some.
I know that this approach would not be considered a best practice, however with that being said, I really want to understand why not. Are there security implications? Would it even work? And if so, are there any "gotchas" or things to consider during implementation?
To reiterate, our lead architect is proposing this solution, and it is failing my gut check, but I don't know enough on the topic to be able to justify my position or else to feel comfortable enough to accept his. Hoping some security experts out there could enlighten me.
It's hard to answer without knowing more on how your current applications and APIs are secured exactly. Do the web application and its API have the same relying party identifier (i.e. can the same token be used to authenticate against both)?
If both web applications use the WS-Federation protocol to authenticate users, then most likely the SAML token will be stored in cookies that were set when the identity provider posted the token back to the application.
You do not have access to these cookies from JavaScript. If the web API that belongs to application B uses the same cookie based authentication mechanism, you could use this provided you allow for cross origin resource sharing.
If your web API uses something like a bearer token authentication scheme (like OAuth) or has a different relying party id in the STS, this would obviously not work.
I think the reason this fails your gut check is because you are basically accessing the web API in a way a cross-site request forgery attack would do it.
A problem I see with this approach is that if the user is not authenticated with the other web application, then the call to your API will also fail.
I agree with user18044 as far as it being based on a cross-site request forgery attack and the security between applications. Is it true that if User X has access to App A, that they will have access to App B and vice versa? If that is not the case, then each application will need to be authenticated separately...and it won't be a SSO. I found these links that might be helpful in your situation.
https://stackoverflow.com/questions/5583460/how-to-implement-secure-single-sign-on-across-various-web-apps
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations
We made a CMS that allows users to connect to Google Analytics via a connector. I'm in the process of porting this connector to OAuth2 and am wondering what kind of application I need to register.
The issue is that the CMS is installed by our clients at arbitrary URL so we don't know the complete set of redirect URLs that I would need to register a Web Server application. Google's OAuth won't let me redirect to an arbitrary URL that I pass in during the authorization request?
Would registering an installed application and then using the urn:ietf:wg:oauth:2.0:oob special redirect URI be best? Seems like this allows the user copy/paste their authorization code from the browser back into our application.
Thanks in advance!
Indeed the installed application will allow users to copy and paste and not register. This is appropriate if the clients are end users of your application, and not say, configuring it as a plugin which will then provide web services to the client's users (where such users will then be prompted via the OAuth2 consent dialog). In the latter case you probably want to ask your clients to register their own web site as web application with Google and use a configuration tool for your CMS application to set the client's redirect URLs.
Why the distinction? Because in the first case the consent action is about your relationship with your clients, but in the latter case it expresses trust between your clients and their users. For instance, you don't want your CMS application to be disabled for abuse because one of your clients has misbehaved, as it'd affect all your clients. However, if you intermediated the consent you made it difficult for Google to understand the distinction.
I recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.