Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We're checking out Auth Providers and was wondering how FusionAuth compares to the others?
First of, FusionAuth is free. Developers can use it for any application and even deploy to production with any number of users. All of the features of FusionAuth are available for free as well.
FusionAuth provides all of the core features that an identity provider must provide. These include registration, login, SSO, MFA, password hashing, password constraints, password reset, email templates, OAuth, OpenID Connect and others. In addition to the core features, FusionAuth also provides localization features, reporting, analytics, user segmentation, user search and a user management UI.
FusionAuth is single-tenant and downloadable. You can download it to your dev box, deploy it on a bare-metal server, run it in any cloud or deploy it to Docker. This provides a lot flexibility and FusionAuth (the company) can host it for you in an AWS private cloud if you need.
Finally, FusionAuth is built to scale. You can spin up new instances of it to handle large login volumes (because password hashing is expensive). We've tested it with a few hundred million users and it performs nicely.
Here's a quick example of just one of the numerous of APIs that FusionAuth provides.
$ curl -H'Content-Type: application/json' \
-d'{"loginId":"test#fusionauth.io", "password":"password"}' \
https://localhost:9011/api/login
This is the Login API and you can find the full documentation here: https://fusionauth.io/docs/v1/tech/apis/login
There are comparison docs to other common solutions like Auth0 here.
https://fusionauth.io/blog/2018/10/19/auth0-and-fusionauth-a-tale-of-two-solutions
At the bottom are links to comparisons to Active Directory, Cognito, Firebase, Ping Identity, Okta, and OneLogin.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm working on a webapp that requires user account management and authentication. The users should be able to login to their account using different tokens - Email, Phone Number, Facebook id, Company account id etc. Same user might be using all of these different methods based on the entry point they choose to login.
From the backend, I should be able to retrieve the correct user account based on any of these tokens. Basically, multiple tokens (email, phone, facebook etc) should point to the same user account.
I have been looking into Firebase and Stormpath. From your experience, do you think Firebase or Stormpath are good options for me? I was wondering if there are good pre-build web solutions for this without re-inventing the wheel by myself.
Please feel free to suggest different web solutions and architecture tips.
Thanks for your time,
Iranga
Disclaimer: I work at Stormpath
Firebase is a platform/ecosystem for building web/mobile applications, and as such they offer an authentication and authorization solution. Building your app with them will require buy-in to their entire platform.
Stormpath is an authentication and authorization service that can be added to any type of application, regardless of where it is ran, where it is hosted, or what your fronted of backend is written in. Our API does allow you to manually link different types of accounts together, e.g. password-based accounts or social accounts. See Modeling Your User Base in our documentation.
We’re adding some support to make this easier and you can follow the Account Linking feature to know when this is available.
In sum: if you want an entire platform for your application, Firebase may be a good fit. If you prefer to maintain more control over your hosting (such as using Heroku to deploy your Nodejs application and have Postgres available), then Stormpath would be the better fit.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am building an Android app - a key part of which will include integration with a server API. The app is just a side-project and I am really just looking for validation of my planned API security and suggestions of best practice and how other apps do it.
The application will be mobile only (to start with, no website) - I want to be able to create user accounts from the app, and once signed up, use the central web API to access/update secured user-specific content.
What I have started looking at is a basic hosted MVC web app (I'm JVM/Spring background, so will likely use those libraries, but the question here is tech agnostic) - the app will have no webpages and just expose a series of endpoints:
Publicly accessible POST endpoints to sign-up & sign-in
OAuth secured endpoints for user specific content (plus of course the normal OAuth dance endpoints needed)
Is that a reasonable approach? Does using OAuth make sense when I have control over the client and server sides?
I assume the official Twitter app just uses OAuth with its API that it exposes to other users? And Instagram was launched as mobile only platform at first, so I assume they must have had in app account creation & then some API security?
(I know there are further considerations/requirements - communication over ssl, protecting your applications oauth key from people de-compiling the application and then using the key in other apps etc, but really I just want some higher-level input if people have implemented these kind of systems before with success/problems etc)
Sounds good, but any token-based sessions would work. Don't store the credentials (at least not the password) on the device. Only store the token, which can be expired, and store it securely. Require HTTPS and use certificate pinning to prevent session hijacking.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Internal to our work group we have a number of services running on our web server including build service, wiki, bug tracker, and some homegrown apps. Currently these all require seperate logins for each service.
The main choice i see to centralize user creation between all these services is LDAP, however i am not interested in doing the full enterprise system, attaching logins and shared directories etc all I want is a way of centralizing users in web services.
From playing with openLDAP this seems complete overkill and is a pain to set up. Is there a simpler method, perhaps speaking LDAP protocol or some other way of centralizing authentication without having to hack up custom external authentication scripts for my services?
A centralized authentication store accessed via LDAP is exactly the solution for which you seek. LDAP is
a small protocol from a wire perspective
most available LDAP servers are extremely fast
the protocol and implemented servers are simple
easy to understand
easy to administrate
easily securable
Add replication for redundancy and increased aggregate throughput and it is hard to imagine a better solution.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
We're establishing an ADFS (2.0) that will be responsible for authenticating users for several, customer-facing systems. The authentication mechanism is out-sourced to an external partner, which offers access to several authentication providers.
We recently ran into the following scenario :
A user attempts to access customer-facing system A and is redirected to the ADFS for authentication.
The ADFS redirects the user to the authentication partner, where he authenticates succesfully.
The user is sent back to the ADFS with his authentication token.
The ADFS sends the user back to system A. He now has a session with it.
The user attempts to access System B, in which he is not yet
authenticated, and is sent to the ADFS.
This is where the ADFS strays from the behaviour we expected. Instead of recognizing the user, and transparently sending him back to System B with a valid authentication token, the ADFS sends him to our authentication partner for re-authentication.
This completely destroys the SSO functionality we wanted for customers using systems A and B, but we have not found a way to have the ADFS establish a user session and re-using that during access to the second system.
Has anyone solved this problem?
Can ADFS only deliver single sign-on when it's wholly responsible for authentication?
The ADFS is expected to behave this way, if your RP-s (System A and System B) have been configured to Force Authentication (ForceAuthn="true"). To resolve your issue, ensure that the freshness attribute is removed from the <wsFederation> element.
In classic ADFS, you set up the different authentication partners as claims providers with ADFS i.e. you federate the respective STS. This then provides the SSO functionality that you require.
It sounds like your problem is that there is only federation between ADFS and the external partner but not between ADFS and the authentication providers handled by the external partner.
Do you have access to the ADFS2 logs? In a Windows machine --> Event Viewer --> Applications and Services Logs --> AD FS 2.0 --> Admin.
Check also that A,B and ADFS2 are in the same circle of trust, and also the Assertion Consumer Services endpoints of the system B.
Hope it helps,
Luis
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 10 days ago.
Improve this question
I've been doing a lot of studying and work recently related to WCF, web services and distributed computing in general, but most of the security concepts go over my head. Transport security, message security, encryption, certificates, etc. I understand the basics of symmetric and asymmetric encryption, but I don't really understand the real world application of them in a SOAP conversation.
I'd read the specs, but they seem a bit dense. Can anyone point me to resources that start with the basics and work up from there? I'm tempted to fish out the textbook from my networking course in college to get a better understanding of what's happening at the lowest level, but I don't know if this is massively inefficient or not. I'd prefer not to have to read a small library full of stuff - I just want to solidly grok the concepts and be able to explain them to the rubber duck on my desk.
Edit:
It's been several years since I first wrote the answer and the list is getting old. There have been some wide adoption of web-enabled APIs and token-based trust relaying.
I haven't read it, but Windows Communication Foundation Security would be a good place to start, if you're looking for something specific to WCF.
Also keep your eyes open for what major players like Facebook, Google, and Twitter are doing. They are using open protocols like OpenID and OAuth. At first, OAuth looks complicated, but you should understand the mechanism.
In my opinion earlier OAuth reinvents a lot of wheels that SSL has already solved, and leaves some security holes open. An interesting read is Compromising Twitter's OAuth security system. Facebook's OAuth 2.0 implementation and Google's OAuth 2.0 implementation simplify many of these issues by using https where it makes sense. These are must reads.
The basic concept around OAuth is trust relaying. You would want third-party developers to make apps against your API, but the end users cannot always trust these apps. Giving password to them, is like giving the keys to the kingdom. So the user types in the password into your UI, and your UI redirects to the third party with an access token.
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication is a good introduction to ASP.NET's security models. You can skip over the details because much of the technology is now obsolete.
A good overview specific to Web Services is Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. It says WSE, but basic concepts still remain the same.
To get more details on WS-Security, read Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption.
After reading above, what really helped me was looking at existing implementations like Amazon S3's authentication:
Amazon S3's authentication http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif
Flickr Authentication API:
Each authentication frob is specific
to a user and an application's api
key, and can only be used with that
key.
Authentication frobs are valid for 60
minutes from the time it is created,
or until the application calls
flickr.auth.getToken, whichever is
sooner.
Only one authentication frob per
application per user will be valid at
any one time. Applications must deal
with expired and invalid
authentication frobs and know how to
renew them.
Twitter REST API
Many Twitter API methods require
authentication. All responses are
relative to the context of the
authenticating user. For example, an
attempt to retrieve information on a
protected user who is not friends with
the requesting user will fail.
For
the time being, HTTP Basic
Authentication is the only supported
authentication scheme. When
authenticating via Basic Auth, use
your registered username or email
address as the username component.
Session cookies and parameter-based
login are known to work but are not
officially supported.
The OAuth
token-based authentication scheme will
shortly be offered as an experimental
beta release.
So it's nice to know the complicated certs and PKI stuff, but the world seems to operate without it just fine.
Additionally, there's also the WCF Security Guidance by Microsoft's Patterns & Practices group. Check it out.
Marc
Start with searching wikipedia for Public Key Infrastructure (PKI) and follow the links to understand the different pieces. You don't need to know the encryption algorithims for the various ciphers, but you do need to understand the concepts if you want to really understand how WCF uses it.