Date: Thu, 28 Mar 2024 14:53:21 +0000 (UTC) Message-ID: <1057481812.11.1711637601225@94194a84deec> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10_109393264.1711637601224" ------=_Part_10_109393264.1711637601224 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Security is the primary reason we use OAuth. Much like our data in= tegration strategy, we don=E2=80=99t want to store any secure data or user = information on any MobileSmith servers. OAuth allows you to control a= ccess to your secure resources, while still having the benefits of quickly = creating rich, native apps.
We also use OAuth because it is an authentication standard in the app in= dustry. Ever see an app that asks you to sign-up/sign-in using Facebo= ok? That=E2=80=99s OAuth!
OAuth (open authentication) is an open standard for authentication. = ; It provides an application (client) secure access to server resources on = behalf of the resource owner. OAuth specifies the process for the res= ource owner to authorize third-party access to their server resources witho= ut sharing login credentials. Instead of a username and password bein= g passed back and forth from an app to a server, the server issues an acces= s token to the application, which is approved on the authorization server.&= nbsp; Once the access token has been given to the application (client), res= ources can be accessed securely without ever exposing a username or passwor= d.
In the above description, the =E2=80=9Capplication=E2=80=9D or =E2=80=9C= client=E2=80=9D is the MobileSmith platform and/or the app made in the Mobi= leSmith platform. The =E2=80=9Cresource owner=E2=80=9D is the party r= esponsible for hosting the data being accessed by the MobileSmith platform/= app. The =E2=80=9Cauthorization server=E2=80=9D (which may also be th= e same server as the resource server) is the server responsible for authori= zing users and granting access tokens to be used later by an application to= get data. The =E2=80=9Cauthorization server=E2=80=9D, by definition,= is not, and cannot be, a MobileSmith server, as we do not want to get/see = your users=E2=80=99 login credentials.
Ultimately, the server containing your data needs to be sure that users = accessing it are supposed to be accessing it. In most methods of auth= entication, including OAuth, some =E2=80=9Cthing=E2=80=9D needs to be passe= d back and forth between the user=E2=80=99s device and the server =E2=80=93= tokens, cookies, encrypted username/password, etc. =E2=80=93 these are all= =E2=80=9Cthings=E2=80=9D used in various forms of authentication. Fo= r OAuth, we=E2=80=99re looking to pass an =E2=80=9CAccess Token=E2=80=9D ba= ck and forth. The question is, =E2=80=9CHow does a user get an access= token from the server?=E2=80=9D Well, here goes!
Once the OAuth access method has been turned on for an app, we will prov= ide you a configuration page that will contain all of the details you=E2=80= =99ll need. To ensure that the app will work once it=E2=80=99s on a m= obile device, the Platform will attempt to authenticate on the authorizatio= n server from inside the browser (in a pop-up window). Once successfu= l, you=E2=80=99ll be able to make secure REST service calls in the Platform= in order to configure new AppBlocks (those that require authentication).&n= bsp; Of course, once you get the app on your phone, you=E2=80=99ll need to = authenticate in order to test the app.
Questions to ask your OAuth pro= vider