Currently I have a problem related to system integration. When I integrate system B into system A (via 1 API name C and 1 authen API for C), but I am only authorized at system B , how can I call API C without authorization at system A?
Authorized between two systems
Related
Problem Statement:
I want to solve the user authentication on Android applications using the FIDO2 protocol(by providing an SDK), without doing multiple registration ceremonies for different applications on the same device.
For example, If a user has been Registered(generated Public-Private key pair) in an Android application A, he/she shall not be required to Registered in an Android application B(Given App A and App B are on the same device).
What could be the possible Solutions(as per my knowledge):-
A common SDK integrated with application A and B to provide authentication.
Separate Authentication App.
I want to go forward with Solution 1 as Solution 2 might not be desirable because it needs an extra step of downloading an extra app(Authentication App).
What am I able to achieve right now:-
We are able to do passwordless authentication of a user for app A and app B by maintaining separate private keys for app A and app B .
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
During the registration step a Public-private key pair is generated by the authenticator.
PrivateKey_1(PrivateKey) gets created and is stored in the Keystore and PublicKey_1(PublicKey) gets created and is shared with the server.
Let's say now that User XYZ wants to login to the app B.
Same process gets repeated for user XYZ to register him with app B.
In this process, A PrivateKey_2 gets created and is stored in the Keystore and PublicKey_2 gets created and is shared with the server.
So in above scenario User XYZ is able to authenticate on App A and App B using private key PrivateKey_1 and PrivateKey_2 respectively.
I want to know the feasibility of the following Scenario?
I want to do passwordless authentication of user XYZ for app A and app B, where applications(app A and app B) can use the same credentials (public and private key pair ) and do not need to perform a repeated registration ceremony(creating public and private key) for the same user on the same device for multiple applications sharing the common SDK(app A and app B).
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
In this process, a PrivateKey_1 gets created and is stored in the Keystore and
PublicKey_1 gets created and is shared with the server.
User XYZ wants to login to the app B.
App B should be able to verify user XYZ using the previously generated
credentials(by app A).
Is this even possible? Is there any gap in my understanding?
Any Suggestion and help is really appreciable :) :)
FIDO2 credentials can be reused wherever the API is available so long as you reference the same RP ID whenever you attempt authentication. FIDO credentials are bound to a unique RP ID, and as long as you can prove ownership of an RP ID then you'll be able to request authentication with any credentials associated to that same RP ID.
In the case of Android, you'll be able to auth across apps so long as both apps are connected to a single website and its unique RP ID. To connect your app to a website, check out the FIDO2 API for Android docs, particularly its section on Interoperability with your website. It links to Google's page for setting up Digital Asset Links on your site so that you can prove ownership of an RP ID and use credentials associated with it for authentication across apps.
Once your apps and website are linked and the user has registered in one app you should then be able to use Fido2ApiClient.getSignPendingIntent() to authenticate in your second app so long as you specify your site's RP ID (the same one specified during registration) as the rpId in the PublicKeyCredentialRequestOptions you pass to the method.
P.S. What's nice about all of this is that credentials you register using Fido2ApiClient (or any equivalent API on other platforms for that matter) in a native app can later be used to log into your website using the WebAuthn API in the browser; you just need to reference the same RP ID in the PublicKeyCredentialRequestOptions you pass to WebAuthn's navigator.credentials.get()!
One of the main benefits of FIDO2 is that it prevents man-in-the-middle attacks where an attacker is trying to impersonate a genuine replying party. The FIDO2 key will only respond to the RP for which the private key is registered. Sharing authn across multiple RPs would break this model. I don't know what is possible on an Android device but I would have thought you would need some form of authentication broker (an IdP) which you auth to with the Key and it is responsible for proving auth to the apps.
Are these accounts registered on the same service? Reading the Android FIDO2 API Interoperability with your website section, it seems possible to host https://example.com/.well-known/assetlinks.json with multiple Android apps listed.
I saw your problem statement and I think you should use SAWO Labs API for solving the authentication part as it is very easy to use. You can use one API key in multiple applications to use the authentication and also this API has a trust feature where you have to authenticate from each application where the same API is used for one time and you will no longer need authentication every time. SAWO Labs API is a passwordless user authentication tool.
You can know more about the SAWO Labs API from the link given below:
https://sawolabs.com/
Consider we have 3 services.
A has public API (Rest) and will call by user from external.
B is internal service which worked independently. B acts as a grpc server.
O OAuth server and even can validate tokens via grpc.
Now,
A should call B sometimes. this calls does not depends on user but they are depended on A itself.
B needs to know which service called it. It uses Authorization metadata (header) and pass it to ClientResolve service.
ClientResolve service validates Authorization header value (token) via O and extracts token's client id. (Or maybe uses some internal implementation such as client table in B and basic authentication token.)
Is it really good idea? Does this design works correctly? Has any conflict with standards or patterns?
We have a single API X which needs to be available both internally and externally to the company. Is it possible to allow basic authentication to X using only a Client Id for internal consumers but require oAuth authentication to X using a Client Id and Auth Token for external consumers? Preferrably, with client id and oAuth fields all passed in the http header to both APIs?
We currently have a single product containing two APIs (API X and an oAuth 2.0 provider API scoped to API X). We have added two security definitions to API X, Option 1 is oAuth and Client Id. Option 2 is Basic (Client Id only). For oAuth, we are using a confidential, application flow scheme where app sends client id and secret to oAuth provider API, and gets back an auth token and then passes the (same) client id and auth token to API X.
OAuth access to API X is working fine using http headers, but Basic access to API X only works if we pass client id in the Query string. We'd prefer to always only use http headers.
I'm still very open to a better answer but We have found a workaround.
We removed the Basic authentication security definition from API X so that it only has the oAuth 2.0 security definition. We then created a new API Y which is identical to API X except that it only has the Basic authentication security definition. It has the same base path and paths as API X. We created a second Product and added API Y to it. Just to recap, Product 1 contains API X and its oAuth API. We subscribed the internal consumers to Product 2 and external to Product 1 and we have success. Authorization is completely handled within the headers.
Surely there is a better way?
I have 3 different web applications.
A,B and C
now when user enter site B or C in web browser then if user already logged in site A then i want user to use the site B or C without any login.
now if user not signed in and trying to access site B or C then first redirect user to site A for login and then redirect to site which he want's to use.
You need to configure applications A, B and C as Relying Parties in ADFS.
All applications need to have a client side stack supporting either WS-Fed (WIF) or SAML 2.0.
If you used ADFS 2016, you could also use OpenID Connect.
That gives you SSO across all applications.
Once you have logged into A, you will not have to login to B and C.
I'm developing 2 Grails applications - A and B - and I would like to support the following use cases
If a user has an account with A, they may also use it to register/login to B (in much the same way as you can use Twitter, Google, etc. credentials to register/login to http://stackoverflow.com). Similarly, if a user has an account with B, it can be used to register/login to A.
Users also have the option to use separate accounts on each site, i.e. they are not forced to use their A credentials on B (or vice versa)
If a user has used their A credentials to authenticate to B (or vice versa) this establishes trust between the 2 sites, allowing A to call an API of B's to retrieve additional information about the user. There needs to be a mechanism that ensures the API can only be called for users that have agreed to share authentication data between the two sites.
Ideally I'd like to use a standards-based approach, e.g. by making each site an OAuth consumer/provider, but I'm not sure which standards are the most relevant standards. If there are any plugins that would help me implement a solution, that would also be useful to know.
I think Stormpath is exactly what you need:
User management API with different SDKs: node.js, express, java, rest, python, flask.
Off the shelf Hosted Login: login, registration, and password reset.
Off the shelf ID Site to power Single Sign-On across your applications
API keys for your users, secured with HTTP Basic Auth or OAuth2
Social Login: Facebook, Google, LinkedIn, Github
Integration with Shiro and Spring Security
Integration with Active Directory and LDAP
In bullet number 3, you are talking about SSO. You can achieve that with Stormpath and Shiro. Please read here.
Disclaimer, I am an Stormpath contributor.