diff --git a/docs/pnp/migration-guides/ios-v6-to-v7.mdx b/docs/pnp/migration-guides/ios-v6-to-v7.mdx index 5ea4ef470..9ce4f7ac0 100644 --- a/docs/pnp/migration-guides/ios-v6-to-v7.mdx +++ b/docs/pnp/migration-guides/ios-v6-to-v7.mdx @@ -19,7 +19,7 @@ import Web3Auth let web3auth = Web3Auth(W3AInitParams( clientId: "", - network: .MAINNET, // you can use .sapphire_devnet or .sapphire_mainnet + network: .mainnet, // you can use .sapphire_devnet or .sapphire_mainnet sdkUrl: ..., redirectUrl: ..., )) @@ -107,8 +107,8 @@ web3Auth = await Web3Auth( #### change of `W3AInitParams` object -The `Web3Auth` constructor takes an object called `W3AInitParams` as input. The below are the aviliable fields of the `W3AInitParams` object. With v7, -additional 2 parameters, which are `MfaSettings` and `sessionTIme` can be set. +The `Web3Auth` constructor takes an object called `W3AInitParams` as input. Below are the available fields of the `W3AInitParams` object. With v7, +additional 2 parameters, which are `MfaSettings` and `sessionTime` can be set. diff --git a/docs/sdk/pnp/android/dapp-share.mdx b/docs/sdk/pnp/android/dapp-share.mdx index c82cebe2b..57cffe1c0 100644 --- a/docs/sdk/pnp/android/dapp-share.mdx +++ b/docs/sdk/pnp/android/dapp-share.mdx @@ -9,15 +9,15 @@ import AndroidResponse from "@site/src/common/sdk/pnp/_userinfo_response.mdx"; ## Web3Auth Infrastructure at a glance -If you go through the [Web3Auth infrastructure](/infrastructure/) you'll notice that to enable the non custodiality of Web3Auth, we -split the private key into multiple parts, ie. `shares`. These shares are a part of the off chain multisig, where multiple shares are stored in -different places and can be used to reconstruct the private key dynamically in the user's frontend application. For a glance at the structure of the -shares, these are the following: +If you go through the [Web3Auth infrastructure](/infrastructure/) you'll notice that to enable the non custodiality of Web3Auth, we split the private +key into multiple parts, ie. `shares`. These shares are a part of the off chain multisig, where multiple shares are stored in different places and can +be used to reconstruct the private key dynamically in the user's frontend application. For a glance at the structure of the shares, these are the +following: -1. **`ShareA` is stored on the user's device**: Implementation is device and system specific. For example, on mobile devices, the share could be - stored in device storage secured via biometrics. -2. **`ShareB` is managed by a login service via node operators**: This share is further split amongst a network of nodes and retrieved via +1. **`ShareA` is managed by a login service via node operators**: This share is further split amongst a network of nodes and retrieved via conventional authentication flows. +2. **`ShareB` is stored on the user's device**: Implementation is device and system specific. For example, on mobile devices, the share could be + stored in device storage secured via biometrics. 3. **`ShareC` is a recovery share**: An extra share to be kept by the user, possibly kept on a separate device, downloaded or based on user input with enough entropy (eg. password, security questions, hardware device etc.). @@ -26,13 +26,13 @@ initial setup provides several benefits. ## The User Experience in Mobile Platforms -The user experience in mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where +The user experience on mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where they can login using their socials and then back to the app once they have been successfully authenticated. This user experience shifts the context -between two applications, whereas in the web platforms, the context remains within the browser only. +between two applications, whereas, in the web platforms, the context remains within the browser only. -For the seamless login flow, we need to reconstruct the Shares `A` and `B`. `Share A` is managed by the login service and is provided on successful -authentication. Whereas in web platforms, `Share B` is stored in the browser context. We can still store it in the browser context for mobile devices, -but this has a few risks, like user accidently deleting browser data. This is a bigger problem in mobile devices since the user doesn't realise that +For the seamless login flow, we need to reconstruct the Shares `A` and `B`. `Share B` is managed by the login service and is provided on successful +authentication. Whereas in web platforms, `Share A` is stored in the browser context. We can still store it in the browser context for mobile devices, +but this has a few risks like users accidentally deleting browser data. This is a bigger problem in mobile devices since the user doesn't realize that the browser is being used to login within the app and clearing the browser data can cause their logins to fail. Hence, to tackle this issue, Web3Auth issues a dApp Share, ie. a backup share that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user. diff --git a/docs/sdk/pnp/ios/custom-authentication.mdx b/docs/sdk/pnp/ios/custom-authentication.mdx index 19fb193b4..9607d2529 100644 --- a/docs/sdk/pnp/ios/custom-authentication.mdx +++ b/docs/sdk/pnp/ios/custom-authentication.mdx @@ -8,8 +8,8 @@ description: "Web3Auth PnP iOS SDK - Using Custom Authentication | Documentation import TabItem from "@theme/TabItem"; import Tabs from "@theme/Tabs"; -This is a document to use a custom login mechanism with the Web3Auth iOS SDK. For example, to login using your own custom JWT issuers like Auth0, AWS -Cognito, or Firebase. You can add the your configuration to the `loginConfig` field of the `W3AInitParams` object. +To use custom authentication (Using Social providers or Login providers like Auth0, AWS Cognito, Firebase etc. or even your own custom JWT login) with +the Web3Auth Swift(iOS) SDK. You can add the configuration to the `loginConfig` field of the `Web3AuthOptions` object. The `loginConfig` field is a key value map. The key should be one of the `Web3AuthProvider` in its string form, and the value should be a `W3ALoginConfig` struct instance. @@ -206,7 +206,7 @@ for enabling login. The `extraLoginOptions` accepts the following parameters: | `client_id` | `string` | The Client ID found on your Auth0 Application settings page. **Use web3auth client id in case of custom JWT login.** | | `redirect_uri` | `string` | The default URL where Auth0 will redirect your browser to with the authentication result. | | `leeway` | `number` | The value in seconds used to account for clock skew in JWT expirations. | -| `verifierIdField` | `string` | The field in jwt token which maps to verifier id. | +| `verifierIdField` | `string` | The field in the jwt token that maps to the verifier id. | | `isVerifierIdCaseSensitive` | `boolean` | Whether the verifier id field is case sensitive. Defaults to `true` | diff --git a/docs/sdk/pnp/ios/dapp-share.mdx b/docs/sdk/pnp/ios/dapp-share.mdx index 0ddf6109c..1c827e9d7 100644 --- a/docs/sdk/pnp/ios/dapp-share.mdx +++ b/docs/sdk/pnp/ios/dapp-share.mdx @@ -9,15 +9,15 @@ import IosResponse from "@site/src/common/sdk/pnp/_userinfo_response.mdx"; ## Web3Auth Infrastructure at a glance -If you go through the [Web3Auth infrastructure](/infrastructure/) you'll notice that to enable the non custodiality of Web3Auth, we -split the private key into multiple parts, ie. `shares`. These shares are a part of the off chain multisig, where multiple shares are stored in -different places and can be used to reconstruct the private key dynamically in the user's frontend application. For a glance at the structure of the -shares, these are the following: +If you go through the [Web3Auth infrastructure](/infrastructure/) you'll notice that to enable the non custodiality of Web3Auth, we split the private +key into multiple parts, ie. `shares`. These shares are a part of the off chain multisig, where multiple shares are stored in different places and can +be used to reconstruct the private key dynamically in the user's frontend application. For a glance at the structure of the shares, these are the +following: -1. **`ShareA` is stored on the user's device**: Implementation is device and system specific. For example, on mobile devices, the share could be - stored in device storage secured via biometrics. -2. **`ShareB` is managed by a login service via node operators**: This share is further split amongst a network of nodes and retrieved via +1. **`ShareA` is managed by a login service via node operators**: This share is further split amongst a network of nodes and retrieved via conventional authentication flows. +2. **`ShareB` is stored on the user's device**: Implementation is device and system specific. For example, on mobile devices, the share could be + stored in device storage secured via biometrics. 3. **`ShareC` is a recovery share**: An extra share to be kept by the user, possibly kept on a separate device, downloaded or based on user input with enough entropy (eg. password, security questions, hardware device etc.). @@ -26,13 +26,13 @@ initial setup provides several benefits. ## The User Experience in Mobile Platforms -The user experience in mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where +The user experience on mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where they can login using their socials and then back to the app once they have been successfully authenticated. This user experience shifts the context -between two applications, whereas in the web platforms, the context remains within the browser only. +between two applications, whereas, in the web platforms, the context remains within the browser only. -For the seamless login flow, we need to reconstruct the Shares `A` and `B`. `Share A` is managed by the login service and is provided on successful -authentication. Whereas in web platforms, `Share B` is stored in the browser context. We can still store it in the browser context for mobile devices, -but this has a few risks, like user accidently deleting browser data. This is a bigger problem in mobile devices since the user doesn't realise that +For the seamless login flow, we need to reconstruct the Shares `A` and `B`. `Share B` is managed by the login service and is provided on successful +authentication. Whereas in web platforms, `Share A` is stored in the browser context. We can still store it in the browser context for mobile devices, +but this has a few risks like users accidentally deleting browser data. This is a bigger problem in mobile devices since the user doesn't realize that the browser is being used to login within the app and clearing the browser data can cause their logins to fail. Hence, to tackle this issue, Web3Auth issues a dApp Share, ie. a backup share that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user. diff --git a/docs/sdk/pnp/ios/initialize.mdx b/docs/sdk/pnp/ios/initialize.mdx index e538345b8..1160236f1 100644 --- a/docs/sdk/pnp/ios/initialize.mdx +++ b/docs/sdk/pnp/ios/initialize.mdx @@ -5,13 +5,13 @@ displayed_sidebar: sdk description: "Web3Auth PnP iOS SDK - Initialization | Documentation - Web3Auth" --- -After Installation, the next step to use Web3Auth is to Initialize the SDK. However, the Initialization can be done in 2 ways, +After Installation, the next step to use Web3Auth is to Initialize the SDK. However, the Initialization can be done in two ways, - [With `Web3Auth.plist`](#with-web3authplist) - [Without `Web3Auth.plist`](#without-web3authplist) Please note that these are the most critical steps where you need to pass on different parameters according to the preference of your project. -Additionally, Whitelabeling and Custom Authentication have to be configured within this step, if you wish to customise your Web3Auth Instance. +Additionally, Whitelabeling and Custom Authentication have to be configured within this step, if you wish to customize your Web3Auth Instance. ## With `Web3Auth.plist` @@ -27,7 +27,7 @@ In your application bundle add a plist file named `Web3Auth.plist` with the foll ClientId YOUR_WEB3AUTH_CLIENT_ID Network - mainnet | testnet | cyan | aqua + sapphire_mainnet | sapphire_devnet | mainnet | cyan | aqua | testnet ``` @@ -42,7 +42,7 @@ let web3auth = Web3Auth() ## Without `Web3Auth.plist` -If you don't have a Web3Auth.plist or want to use optional configurtion parameters, you can construct the Web3Auth instance with +If you don't have a Web3Auth.plist or want to use optional configuration parameters, you can construct the Web3Auth instance with ```swift import Web3Auth @@ -57,18 +57,18 @@ let web3auth = Web3Auth(W3AInitParams( ### `W3AInitParams` object -The `Web3Auth` constructor takes an object called `W3AInitParams` as input. The below are the aviliable fields of the `W3AInitParams` object. +The `Web3Auth` constructor takes an object called `W3AInitParams` as input. Below are the available fields of the `W3AInitParams` object. | Parameter | Type | Mandatory | Description | | ---------------- | --------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `clientId` | String | Yes | Your Web3Auth project ID | | `network` | Network | Yes | Web3Auth Network to run the authentication on, either `.mainnet`,`.aqua`, `.testnet`, `.cyan`, or `.sapphire_devnet` or `.sapphire_mainnet` | -| `buildEnv` | BuildEnv | No | Obtion for auth service, `production`, `staging`, `testing` available | +| `buildEnv` | BuildEnv | No | Option for auth service, `production`, `staging`, `testing` available | | `sdkUrl` | URL | No | Web3Auth sdk frontend to be used. This field is for advanced usage only and should not be changed. | -| `redirectUrl` | String | No | redirectUrl to be passed to the sdk frontend. This field is for advanced usage only and should not be changed. | +| `redirectUrl` | String | No | redirectUrl to be passed to the SDK frontend. This field is for advanced usage only and should not be changed. | | `whiteLabel` | W3AWhiteLabelData | No | A configuration optional object to customize UI, branding, and translations for your brand. Refer to the WhiteLabeling section for more info. | | `loginConfig` | `[String : W3ALoginConfig]` | No | A configuration optional object to customize login flow. | | `useCoreKitKey` | `bool` | No | Use CoreKit Key to get core kit key. | | `chainNamespace` | `ChainNamespace` | No | Chain Namespace [`eip155` and `solana`] | | `MfaSettings` | `MfaSettings` | No | Settings for Multi factor authentication | -| `sessionTIme` | Int | No | Session maintainance time | +| `sessionTime` | Int | No | Session maintenance time | diff --git a/docs/sdk/pnp/ios/install.mdx b/docs/sdk/pnp/ios/install.mdx index 1481a8670..470e2326b 100644 --- a/docs/sdk/pnp/ios/install.mdx +++ b/docs/sdk/pnp/ios/install.mdx @@ -17,7 +17,7 @@ description: "Installing Web3Auth PnP iOS SDK | Documentation - Web3Auth" https://github.com/Web3Auth/web3auth-swift-sdk ``` - From the `Dependency Rule` dropdown, select `Exact Version` and enter `7.4.0` as the version. + From the `Dependency Rule` dropdown, select `Exact Version` and enter `7.4.1` as the version. 1. When finished, Xcode will automatically begin resolving and downloading your dependencies in the background. @@ -29,7 +29,7 @@ pod 'Web3Auth', '~> 7.4.1' ## Configuration -In order to use Web3Auth you need to provide your Web3Auth `ClientId` and which `Network` to run it. +To use Web3Auth you need to provide your Web3Auth `ClientId` to the SDK. - Go to [Web3Auth Developer Dashboard](https://dashboard.web3auth.io), create or open an existing Web3Auth project and copy your Client ID, which is the `ClientId`. diff --git a/docs/sdk/pnp/ios/ios.mdx b/docs/sdk/pnp/ios/ios.mdx index 6d85e2eda..1e156a911 100644 --- a/docs/sdk/pnp/ios/ios.mdx +++ b/docs/sdk/pnp/ios/ios.mdx @@ -5,9 +5,9 @@ displayed_sidebar: sdk description: "Web3Auth PnP iOS SDK | Documentation - Web3Auth" --- -For using Web3Auth in natively in iOS, Web3Auth provides an [iOS SDK](https://github.com/Web3Auth/web3auth-swift-sdk), written in Swift. The Web3Auth -iOS SDK is a client-side library you can use with your iOS app to authenticate users using Web3Auth. It returns a private key generated in a non -custodial way on successful authentication of the user. This authentication can be achieved by using any of the social logins Web3Auth provides or +For using Web3Auth natively in iOS/Swift, Web3Auth provides an [iOS SDK](https://github.com/Web3Auth/web3auth-swift-sdk), written in Swift. The +Web3Auth iOS SDK is a client-side library you can use with your iOS app to authenticate users using Web3Auth. It returns a private key generated in a +noncustodial way on successful authentication of the user. This authentication can be achieved by using any of the social logins Web3Auth provides or using a custom authentication flow of your choice. #### This Documentation is based on the `7.4.1` SDK Version. @@ -23,7 +23,7 @@ using a custom authentication flow of your choice. - [Quick Start](/quick-start?product=Plug+and+Play&sdk=Plug+and+Play+iOS+SDK): Integrate Web3Auth in 4 Simple Steps. - [Integration Builder](/integration-builder?lang=IOS&chain=ETH&evmFramework=WEB3&customAuth=NONE&mfa=DEFAULT&whitelabel=NO&useModal=YES&web3AuthNetwork=TESTNET&rnMode=EXPO&stepIndex=0): - Get customised integration code with detailed reference for your specific use case. + Get customized integration code with detailed references for your specific use case. - [Example Applications](/examples?product=Plug+and+Play&sdk=Plug+and+Play+iOS+SDK): Explore our example applications and try the SDK yourself. diff --git a/docs/sdk/pnp/ios/usage.mdx b/docs/sdk/pnp/ios/usage.mdx index 6543c84ca..d54a20611 100644 --- a/docs/sdk/pnp/ios/usage.mdx +++ b/docs/sdk/pnp/ios/usage.mdx @@ -32,16 +32,16 @@ the login method for specific social logins such as Google, Apple, Facebook, etc -| Parameter | Type | Mandatory | Description | -| ------------------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `loginProvider` | `String` `Provider` | No | Login provider, supported values are `GOOGLE`, `FACEBOOK`, `REDDIT`, `DISCORD`, `TWITCH`, `APPLE`, `GITHUB`, `LINKEDIN`, `TWITTER`, `WEIBO`, `LINE`, `EMAIL_PASSWORD`, `EMAIL_PASSWORDLESS`,`JWT` | -| `extraLoginOptions` | `ExtraLoginOptions` | No | You can pass various oauth supported options, default is `nil` | -| `sessionTime` | `Int` | No | Session time to be passed to set the session of a user that will be returned to Web3AuthState | -| `redirectUrl` | `String` | No | Url where user will be redirected after successfull login. By default user will be redirected to same page where login will be initiated, default is `nil` | -| `appState` | `String` | No | `appState` can be used to keep track of the app state when user will be redirected to app after login, default is `nil` | -| `mfaLevel` | `enum` | No | MFA level can be used to pass 2FA screen shown during login, default is `nil`, shown every 3rd login. | -| `dappShare` | `String` | No | Dapp share can be used to pass dapp share url, default is `nil` | -| `curve` | `enum` | No | Curve can be used to pass curve options, `ED25519` for Solana and `SECP256K1` for Ethereum, default is `SECP256K1`. | +| Parameter | Type | Mandatory | Description | +| ------------------- | ------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `loginProvider` | `String` `Provider` | No | Login provider, supported values are `GOOGLE`, `FACEBOOK`, `REDDIT`, `DISCORD`, `TWITCH`, `APPLE`, `GITHUB`, `LINKEDIN`, `TWITTER`, `WEIBO`, `LINE`, `EMAIL_PASSWORD`, `EMAIL_PASSWORDLESS`, `JWT` | +| `extraLoginOptions` | `ExtraLoginOptions` | No | You can pass various OAuth-supported options, default is `nil` | +| `sessionTime` | `Int` | No | Session time to be passed to set the session of a user that will be returned to Web3AuthState | +| `redirectUrl` | `String` | No | Url where user will be redirected after successfull login. By default user will be redirected to the same page where login will be initiated, the default is `nil` | +| `appState` | `String` | No | `appState` can be used to keep track of the app state when the user is redirected to the app after login, default is `nil` | +| `mfaLevel` | `enum` | No | MFA level can be used to pass 2FA screen shown during login, default is `nil`, shown every 3rd login. | +| `dappShare` | `String` | No | Dapp share can be used to pass dapp share url, default is `nil` | +| `curve` | `enum` | No | Curve can be used to pass curve options, `ED25519` for Solana and `SECP256K1` for Ethereum, default is `SECP256K1`. | diff --git a/docs/sdk/pnp/react-native/dapp-share.mdx b/docs/sdk/pnp/react-native/dapp-share.mdx index 4f1316fc1..fffceabf5 100644 --- a/docs/sdk/pnp/react-native/dapp-share.mdx +++ b/docs/sdk/pnp/react-native/dapp-share.mdx @@ -24,13 +24,13 @@ initial setup provides several benefits. ## The User Experience in Mobile Platforms -The user experience in mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where +The user experience on mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where they can login using their socials and then back to the app once they have been successfully authenticated. This user experience shifts the context -between two applications, whereas in the web platforms, the context remains within the browser only. +between two applications, whereas, in the web platforms, the context remains within the browser only. For the seamless login flow, we need to reconstruct the Shares `A` and `B`. `Share B` is managed by the login service and is provided on successful authentication. Whereas in web platforms, `Share A` is stored in the browser context. We can still store it in the browser context for mobile devices, -but this has a few risks, like user accidently deleting browser data. This is a bigger problem in mobile devices since the user doesn't realise that +but this has a few risks like users accidentally deleting browser data. This is a bigger problem in mobile devices since the user doesn't realize that the browser is being used to login within the app and clearing the browser data can cause their logins to fail. Hence, to tackle this issue, Web3Auth issues a dApp Share, ie. a backup share that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user.