I recently started developing an app and wanted to address authentication from the start.
My only requirement was the identification of users and authentication methods like "Sign-In with google". Implementing it myself is usually not a good idea when it comes to security topics. Therefore I wanted to start my first attempt with the most known service, KeyCloak. The more I became familiar with KeyCloak, the more dissatisfied I became. It's very heavyweight. Difficult to understand. I don't need most of the features and a test integration is tricky.
So now i'm here writing this post and asking for your opinion.
Is there a better and lightway alternative to keycloak?
Should i implement it (f. e. JWT) by myself?
Should i dig deeper into the keycloak docu?
Thanks for your help :)
I have a web application / website written in ASP.NET Core. The website is for use by one company and will be accessible over the internet. Because it is for a specific company it therefore has to have authentication for that client only (no public registration).
Is there a service with a C# API that allows me to define what domain is allowed to register and sign in? For example all emails in a specific domain or specific emails in a specific domain e.g. #someCompany.com under google or outlook? I am not yet aware of what email client the customer uses. I am also new to setting up authentication for a web app.
This may seem like a 'whats the best solution' kind of question but what I am asking for is a solution to a very technical problem. There will be opinions on best solution but I think the question is valid here. Happy to be convinced otherwise.
First of all, I apologize in advance for my naïveté on the topic.
I am trying to create a few microservices that are exposed using an API gateway. A few of these services will need credentials from Google account to access Google Calendar/Gmail etc.. is there any way for a user to only have to login once so that the credentials are all shared between the services? Or should only one service be facing the Google services with credentials?
It seems possible, you can ask a user to authenticate and authorize all permissions your application will need, all at once. But think about the user, when an application requires to access gmail, hangouts, photos, camera, etc. at once, the user normally disbelieve the application. So, the recommended approach is asking for the specific permission when the application requires it so that the user can realize each action you app do.
There exist many different ways to address your question depending on details, however the following link can help you to know where to start:
This link (Google Sign-in) has a wide context on all the Identity mechanisms to look for the most appropriate for you.
This another one explain all possible Identity mechanisms for specific use cases.
This authentication example for Google Calendar is useful, but this post explain how microservices authentication and authorization was solved.
I have a question about API authentication/authorization. I may have some trouble articulating the question, so bear with me.
First of all, I understand how to authenticate end users via an API. That's no mystery to me.
What I want to do is authenticate certain apps as users of my API. I would have some roles so that each user would have different privileges depending on that user's role. You can do different things depending on whether you're one of my mobile apps or you're some third-party API consumer.
Has anyone done this sort of thing, where you have not end users talking to an API, but "app users"? Is there any documentation you can point me to about it? Does this practice have a name?
This type of authentication is known as application authentication (as opposed to user authentication).
Twitter provides a good overview of how to achieve this with Twitter applications. The article also serves as a good introduction to the general practice of application authentication.
https://dev.twitter.com/docs/auth/application-only-auth
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.