I am working on a skill where i want to link the skill to a 3rd party api. The issue is the 3p server does not have Oath enabled and works off on username/password authentication.
I wanted to understand what are my options here. Can i create a middleware which works on oath authentication and then calls the api via username/password?
Any pointers on this would be great to help me move forward.
Amazon's account linking system is made mainly for services with OAuth 2 authentication, or no authentication at all. It doesn't support services that require authentication that cannot support the OAuth 2 standard.
Since you don't control the 3rd party API your options are, hence, more limited.
Technically speaking, it is feasible to create your own 'middleman' credential service, which implements OAuth 2 and serves as a proxy to talk to the external 3rd party API. However, this would violate Amazon's security policy, which states: "you may not handle, store or transmit credentials on behalf of the user." So your skill may not be allowed if you try to do it this way. Even if it were allowed, it's pretty risky storing plaintext credentials on your server for users in this way.
Since (I assume) you don't control the 3rd party API, there's not really any way you can do this with Amazon's account linking feature.
Related
Google supports several identity verification flows for third parties:
https://developers.google.com/identity/choose-auth
Looking at OAuth, the cryptographic primitive is that I can connect using HTTPS and Google can assert to me the identity of the visitor.
This method does not allow me to prove to another skeptic that this certain person completed Google login. This is because HTTPS is plausible deniable.
Is there a different login mechanism for Google where I can prove to a third party that a certain person logged in?
I'm not sure if plausible deniability in the cryptographic sense is applicable to HTTPS - if I understand it correctly you'd need specific support for multiple keys decoding the message in different ways for that, i.e. special software, not just HTTPS.
But regardless, Google authentication (and any other 3rd party identity provider service) fundamentally relies on the trust in the information coming from the identity provider.
If you don't consider the 3rd party identity provider supplied information good enough as proof for another skeptic then you won't be able to use any such identity provider service, you'd have to roll out your own authentication scheme.
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.
I have my own identity authority set up using the Identity Server.
I'm running a native windows application and currently I'm using IdentityModel's OidcClient library to connect on the authority and obtain the token.
I want to add support for Azure AD and since I haven't been able to set-up the application on the Azure AD to use HybridWithProofKey flow, and found this MSAL I've decided to give it a shot.
In MSAL there is a PublicClientApplication class with accepts the string authority in its constructor (source)
When passing my URL in this constructor I imagined it would use the discovery service and found the correct endpoints and to its job. But to my suprise this dont work.
I get following error message:
AADSTS50049: Unknown or invalid instance.
Search on github MSAL for AADSTS50049 returned zero results. I've cloned the project and started with debugging.
I've figured out that the request is sent to my authority url but instead there is a GET request on the
GET https://login.microsoftonline.com/common/discovery/instance?api-version=1.0&authorization_endpoint=https%3A%2F%2Fmyidentityserverhostname%2Fidentityserver%2Foauth2%2Fv2.0%2Fauthorize HTTP/1.1
This request is done in this source and it returns the error above.
So, is MSAL intended to use with non azure authorities?
No. It's a proprietary client library for their proprietary backend.
Yes it can,
You need to use the Azure B2C library, it can be configured with other identity provideer, like facebook, google, linked in etc.
There is also an option to utilise a custom IDP, if it conforms to openId
See here.
https://go.microsoft.com/fwlink/?linkid=854174
Using MSAL.NET with a non-MS OpenID Connect provider is unnecessary, as Microsoft.AspNetCore.Identity provides sufficient support for social logins and other OIDC providers.
Also vendors of custom OpenID Connect servers provide own extensions (see IdentityServer docs and OpenIdDict samples).
As per this official example, MSAL is not required if you're only signing users in. They claim:
MSAL is used for fetching access for accessing protected APIs
BTW, if you're interested in MSAL.JS, then it's a completely different story – https://stackoverflow.com/a/73618966/968003.
What's the difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols?
My understanding on these protocols gets confused when SAML is used as a security token in WS-Trust and WS-Fed protocols.
Interested in knowing in which scenario these protocols used and what makes them different. Your answers will be easy to understand if NO commercial product/ technology references used.
At a high level, WS-* protocols traditionally were used by Microsoft.
SAML-P (P for protocol) was used by the open source movement and hence Java.
WS-Fed has two profiles - active and passive. Active is for WCF (WS-Trust), passive is browser based (WS-Fed via login page).
Both of these use SAML tokens.
Functionally, both WS-Fed and SAML do the same thing wrt. federation
If you federate two ADFS (Microsoft IDP) together you use WS-Fed. If you add in Sharepoint, it also uses WS-Fed. The tokens passed are in the SAML token format.
If you have a Java application that uses Spring, then that will hook in to ADFS via SAML-P. The tokens passed are in the SAML token format.
this question is old but i struggled finding a correct answer online.
A lot of online posts say, that 'passive / browser' clients use WS-Fed and 'active / smart' use WS-Trust. That is probably because the active use case uses by default a url like '/ws-trust/2005' or '/ws-trust/v1.x/'. This does not seem to be 100% accurate. The great and free book: Claims-based Identity, Second Edition helped me with the issue and I finally found a satisfying answer:
The goal of many of these architectures is to enable federation with either a browser or a smart client. Federation with a smart client is based on WS-Trust and WS-Federation Active Requestor Profile.
These protocols describe the flow of communication between smart clients (such as Windows-based applications) and services (such as WCF services) to request a token from an issuer and then pass that token to the service for authorization.
Federation with a browser is based on WS-Federation Passive Requestor Profile, which describes the same communication flow between the browser and web applications. It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.
SAMLP is just a different protocol when it comes to how things are communicated such as the redirection URL and so on, but the differences are not relevant (in most cases) and simply depend what the client supports (e.g. Java will use SAML). The biggest difference is in my opinion that SAMLP allows an Identity Provider initiated Use Case (which is the most secure one in my opinion), where the User starts on the Identity Provider (e.g. the Web Proxy of your ADFS Server, =Claims Provider in MS terms), instead of starting at the Web Service and then getting redirected to the Service Provider (=Relaying Party in MS terms). Also when we are talking about SAML we usually mean SAML 2.0 while WS-Fed uses SAML 1.x Tokens (and MS calls them Tokens, SAML calls them Assertion... its just a signed and possibly encrypted XML, I think theoretically you could use other Tokens in WS-Fed then SAML but i have never heard of anybody actually doing that).
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.