Does Mashery play nicely with a third party OAuth2/OpenID Connect provider? Can it be configured to allow OAuth2 tokens to pass through? If so, how much functionality of Mashery is lost by going with a different identity provider?
I am currently using IdentityServer4 but will soon be using Mashery and I'd like to understand the implications of using both.
Are you asking if Mashery support oAuth tokens generated by external parties ?
Answer is no. And I don't think they have any plans to implement it soon.
Related
I'm planning to federate external Identity Providers (Google,Microsoft,GitHub,...) to my applications.
In my applications for security reasons we want MFA to be enabled for every user.
Is there any way to detect if the user authenticated himself using "Google" with MFA?
I understand that federating an external Idp, the user identification responsibility is transferred to the external Idp, so I doubt that what I'm asking would be possible.
Thanks in advance.
OaicStef
P.S.: In my applications, I manage the authentication with Identity Server 4.
The amr claim is what you're looking for but it's optional so it's not for certain that all providers will provide it and if they do they may provide the data in different ways - e.g. one might return ["pwd","otp"] to describe a situation where a password and a one-time code were used and another may just just use "mfa".
The best thing to do would be to experiment and observe what each service does both with and without MFA enabled and adapt as neccessary.
If it's not something you can guarantee then there's also the option of implementing your own MFA features - libs for using TOTP-based authenticator apps or FIDO2/WebAuthn are readily available.
I have a situation where I currently call web focus reports from our JAVA web applications. But is not a secured way calling and I wanted to implement SAML authentication and pass parameters through SAML. Any help in this regard will be great help
Is there a reason you need SAML?
OpenID Connect is a much easier option.
For SAML, you need to implement a SAML stack.
There is more information here.
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 have a SharePoint publishing site with anonymous access hosted on internet. As per the latest requirements, we need to implement user login (AzureAD, Microsoft personal and work accounts, and more) for some pages within the portal.
There are two approaches we have come up with:
Using msal.js file. Implementing login of user at client side itself and calling Partner Center Web API with user token to check the validity of the user plus performing required operations.
Create a Web API with with Microsoft.Owin.Security.OpenIdConnect nuget package at Web API end to implement login and also use it for doing out required operation of retrieving and modifying data from the backend.
Which approach may work best in our scenario?
Is there any other way to achieve this?
The difference between these two approaches is that they are using the different flows to integrate with the identity data provider.
The second approach that using the server-side code is using the authorization code grant flow which is a stand flow to interact with identity data provider.
The first approach that using the msal.js is using the implicit flow. is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
More detail the flows using the OAuth 2.0 are defined in the OAuth 2.0 Authorization Framework.
I am building an AngularJS application with a Laravel API. I am looking for authentication for a couple of days, but I am stuck.
I found OAuth 2.0 as a kind of default authentication, also used by Facebook and Twitter and so more. A lot of tutorials I found are about using OAuth 2.0 with Facebook and Twitter or Google. But, I do not want to authenticatie a user with Facebook, but I want to build my own authentication, using the user credentials in my own database. So I guess, I need my own OAuth provider.
The authentication has to be very secure and easy to connect for other companies, who want to use our data (it is a web application for primary schools).
I believe there are a lot of answers possible on this question. But, I also believe a lot of people have the same question ;)
Who can explain me how to use OAuth 2.0 or a similar authentication method?
You are right - if you want to implement OAuth 2.0 you need to be your own provider (or authorization server). Being your own provider also means you can actually skip some parts of the process (e.g. the screen with a confirmation if the user really wants to grant this application the right to that etc...)
If you decide to go with OAuth 2.0, there's a widely used package called oauth2-server-laravel that helps with the whole process.
However you could also develop you're own token-based authentication system. Actually the basics are pretty simple:
Login
Verify credentials
Generate token
Store token in database
And then on request you check if the token is in the database (and hasn't expired yet)
Dead simple right? Well.. as you may already know, that's too easy to be true.
Especially where security is of high importance, You have to consider every case and you should really know what you're doing. That's why I recommend you use the OAuth standard. Yes, it may be a bit of an overkill but I believe it's worth it.
Hope I could help :)