react-native-app-auth | React native bridge AppAuth - an SDK | OAuth library
kandi X-RAY | react-native-app-auth Summary
kandi X-RAY | react-native-app-auth Summary
This versions supports react-native@0.63+. The last pre-0.63 compatible version is v5.1.3. React Native bridge for AppAuth-iOS and AppAuth-Android SDKS for communicating with OAuth 2.0 and OpenID Connect providers. This library should support any OAuth provider that implements the OAuth2 spec. We only support the Authorization Code Flow.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Performs an authorization request .
- Convert registration response to a map .
- Converts a JSONObject to a WritableMap
- Initialize Flipper
- Convert an authorization code response to a map .
- Opens a connection to the given URI .
- Convert end session response to map .
- Formats a timestamp .
- Create view managers .
- Returns the main component name for this example .
react-native-app-auth Key Features
react-native-app-auth Examples and Code Snippets
Community Discussions
Trending Discussions on react-native-app-auth
QUESTION
I have a few concerns with an OpenId Connect strategy that I would like to use and have been unable to find specifics on what the security concerns may be and any glaring issues with it I am overlooking.
Currently, I have an OpenId Connect implementation using Openiddict with Authorization Code flow. For the client, I have a React-Native app using react-native-app-auth.
I see from other questions on SO and from issues posted on the Openiddict repo that the recommended approach to third-party providers (e.g. Google) is: Client -> Auth server -> Google Auth -> Auth server -> Client/Auth server code and token exchange
However, it seems that a better approach from a UX standpoint (when using a SPA or native app) would be to implement something similar to GoogleSignIn on the client and either handle the identity on the server using an IdToken or authorization code from Google. This introduces an issue as the flow previously recommended could not be used as the entire initial challenge and redirect from Auth server to Google Auth has been skipped.
I have seen that this issue is mitigated by not using the authorization code grant and instead implementing a custom assertion grant. This seems to be an alright approach but would require exposing a custom grant and handling the flow differently on the client and server for local and third-party logins.
My proposed solution continues to use the authorization code flow and instead of adding a custom grant type the client could just pass a third-party identifier "Google" and the token or authorization code in the additional parameters of the OIDC authorize request. The authorize endpoint could then detect the provider and token, perform token validation, create a user or principal from it, and create an authorization code to send back to the client for the code/token exchange. This flow would look like the following:
1. Get the id token from the provider Client -> GoogleSignIn -> Client
2. Pass token to auth server and initiate code / token exchange Client -> Auth Server -> Auth server Verify Google IdToken (JWKS, issuer, audience, provider specific validation, etc...) or exchange auth code -> Auth server -> Client/Auth server code and token exchange
One downside to this approach would be the additional hops to verify the token on the server side. If the token was returned from GoogleSignIn, they themselves said that it could be trusted. https://developers.google.com/identity/protocols/oauth2/openid-connect#obtainuserinfo
I see that it is generally recommended to place the auth server between the client and the third-party but in this process the server is still between the client and auth server but only after the initial exchange from the client and third-party.
Questions,
In general am I missing something with this flow?
In this case would it be necessary to verify the token on the server side?
Is there some better way to approach this that I have completely overlooked?
Am I making this too complicated and UX should not be this much of a concern?
Instead of adding the provider and token to the additional parameters would it make more sense to pass it in the body of a post request? I don't see the issue with passing it via query string but that's also part of the reasoning for the authorization code grant from my understanding.
Apologies in advance for anything I have missed or omitted for brevity that should have been included.
Thanks.
...ANSWER
Answered 2022-Feb-14 at 14:27ARCHITECTURE
I'm not sure I understand the UX problem - your existing architecture feels really good. If you want to login directly to Google, just send an acr_values=google query parameter in the authorization redirect, to bypass any authentication selection screens. The exact value will depend on how Openiddict represents the Google authentication option, and some providers use a non-standard parameter such as idp. Have a closer look at the OIDC request parameters.
A key OAuth goal is that the Authorization Server (AS) - Openiddict in your case - shields your apps from all of the provider differences and deals with their nuances and vendor specific behaviour. Your apps then also only receive one type of token, and only ever use simple code. As an example, the Curity AS supports all of these options, none of which requires any code in applications.
APPAUTH AND UX
If a user is already signed in then it can, as you say, look unnatural to spin up the system browser and them it is dismissed immediately.
A common option is to show the consent screen or an interstitial page to keep the user informed - and the user clicks one extra button. This can also be useful for getting password autofill to work. My code example and blog post shows how this might look, though of course you can improve on my basic UX.
OFFLINE ACCESS
I find this term misleading, since refresh tokens are most commonly used when the user is there. Are you just asking how to deal with tokens in a mobile client? Aim for behaviour like this:
- Standard messages for API calls with access tokens in an authorization bearer header
- Standard refresh token grant messages to refresh access tokens - eg as in this code
Note also that mobile apps can save tokens to encrypted secure mobile storage that is private to the app. This can improve usability, eg by avoiding logins every time the app is restarted. You should think through scenarios such as stolen devices and token lifetimes though.
QUESTION
I'm developing an app for ios and android in react native and need to use keycloak for authorization, but struggling to find a good way.
I've tried react-native-app-auth and it works good to sign in but not to sign out. Not so strange because react-native-app-auth states that: "Keycloak does not specify a revocation endpoint so revoke functionality doesn't work."
I've had a look at a few other npm packages such as react-native-login-keycloak but they seem to lack maintenance and opens a lot of browser tabs.
Any ideas of how to solve this or maybe do a work-around for react-native-app-auth? Thank you for your help!
...ANSWER
Answered 2020-Jun-04 at 17:17Check the openid-connect configuration endpoint.
You can find it in your keycloak server
https://{your-keycloak-server}/auth/realms/{your_realm}/.well-known/openid-configuration
you will find the endpoints for:
authorization_endpoint
token_endpoint
end_session_endpoint
Add those to your react-native-app-auth configuration.
QUESTION
I'm a noob in the world of React-Native development and am trying to work out how to configure FormidableLabs' react-native-app-auth plugin so that a user of our app can sign in to our Identity Server 4 implementation and then return to the app.
I can get to the sign-in form easily enough - but after signing in it goes to another Identity Server page in the browser rather than back to the app. I assume this is because of a wrong configuration, but I've searched the net far and wide for an answer that actually explains what the redirectUrl should actually point to - in all the examples it just points to io.identityserver.demo:/oauthredirect. Is it possible to redirect back to an app?
What I've also noticed is that the original request to the login page does not pass it a ReturnUrl - that parameter is null.
I feel I'm missing something obvious here, but I cannot think what it is.
Here's the relevant code from the app:
...ANSWER
Answered 2020-Jul-05 at 17:26You are on the right track, once the user has logged into IdentityServer it will redirect back to redirectUrl.
I suggest you to read the docs as it has it explained with example code.
QUESTION
I have setup deep linking in my app previously and had it work just fine. All the sudden it stops working. I have the below manifest...
...ANSWER
Answered 2020-Feb-11 at 18:34The reason for not able to redirect while typing/pasting URL in your browser is due to a bug in Chrome browser itself. but that turned out to be an functionality and adopted by some other browsers as well
You can check the bug here, and look at the status: WontFix (Closed).
Now the reason behind all this according to them,
If a user typing/pasting URL in browser then the user really want to go that URL, instead being redirected on a application
So your deep linking is working fine, best way to test it, share the link and then click on it
And also this always redirection really caused problem as well, when user was not able to go on the website due to redirection, you can also check a bug report here due to this always redirection, status is now Fixed (Closed) for it
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install react-native-app-auth
Install native dependencies
Register redirect URL scheme
Define openURL callback in AppDelegate
CocoaPods cd ios pod install
Carthage With Carthage, add the following line to your Cartfile: github "openid/AppAuth-iOS" "master" Then run carthage update --platform iOS. Drag and drop AppAuth.framework from ios/Carthage/Build/iOS under Frameworks in Xcode. Add a copy files build step for AppAuth.framework: open Build Phases on Xcode, add a new "Copy Files" phase, choose "Frameworks" as destination, add AppAuth.framework and ensure "Code Sign on Copy" is checked.
Static Library You can also use AppAuth-iOS as a static library. This requires linking the library and your project and including the headers. Suggested configuration: Create an XCode Workspace. Add AppAuth.xcodeproj to your Workspace. Include libAppAuth as a linked library for your target (in the "General -> Linked Framework and Libraries" section of your target). Add AppAuth-iOS/Source to your search paths of your target ("Build Settings -> "Header Search Paths").
CFBundleURLName is any globally unique string. A common practice is to use your app identifier.
CFBundleURLSchemes is an array of URL schemes your app needs to handle. The scheme is the beginning of your OAuth Redirect URL, up to the scheme separator (:) character. E.g. if your redirect uri is com.myapp://oauth, then the url scheme will is com.myapp.
swift-Bridging-Header.h should include a reference to #import "RNAppAuthAuthorizationFlowManager.h, like so:
AppDelegate.swift should implement the RNAppAuthorizationFlowManager protocol and have a handler for url deep linking. The result should look something like this:
Note: for RN >= 0.57, you will get a warning about compile being obsolete. To get rid of this warning, use patch-package to replace compile with implementation as in this PR - we're not deploying this right now, because it would break the build for RN < 57.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
