10-16-2023 02:02 PM
We have an Oculus game available on the store alongside a web portal designed to help users manage their account information.
We're eager to provide users with the convenience of logging into our web portal using their Oculus account, ideally through some form of OAuth or Single Sign-On (SSO) mechanism.
The primary resource I've come across regarding this integration is the documentation on "Account Linking".
In essence, here's the flow:
Our web portal initiates the user's redirection to the Meta SSO URL, which can be found at https://auth.oculus.com/sso/?redirect_uri=https://someloginuri.com/oa&organization_id=12345678123456....
The user agrees to link their account with our web portal.
Following the agreement, the user is redirected back to our web portal, accompanied by encoded data we can leverage for authenticating the user within the Oculus API.
The account linking process does indeed work, yet there's a recurring issue. Users are prompted to "CONNECT ACCOUNT" each time they visit the Meta page for login (see picture below). Ideally, we expected this step to be a one-time event. However, it seems users encounter this step upon each visit, which can hinder the user experience in our web login process.
I'm wondering if there exists a workaround for this particular issue. Have I overlooked any crucial details in the documentation? Is there a method to only present the account linking step once, followed by a seamless and conventional login flow thereafter?
Any suggestions would be greatly appreciated!
Solved! Go to Solution.
02-21-2024 03:20 AM - edited 02-21-2024 03:23 AM
After reaching out to Meta support, we came to understand that the "Account linking" flow mentioned above is the only way to accomplish a "Sign in with Quest/Oculus" functionality. It is not ideal since it was not meant to support log ins (and prompts users to "Connect account" every time they want to log in), but it does work.
Here was their answer: "I don't believe the feature is meant for a 'Sign In with Quest' style functionality, but rather to attach a user to an account that you maintain on your own servers."
FYI: ShapesXR also uses the same login flow.
10-18-2023 10:24 AM
To clarify my question above, once we obtain the auth token and refresh token from step 4 (see documentation), we can make requests on behalf of the user to the Oculus API. As per the documentation, it suggests storing these tokens in our client and using the refresh token when necessary, especially as we approach the 30-day token expiration. This approach ensures that the user remains logged in as long as we possess a valid auth token.
However, our objective is slightly different. We prefer to keep our users signed in for a shorter duration, around 2 hours. After this time, they would need to go through steps 2 to 4 again for reauthentication.
We're looking to implement an Oculus OAuth login flow similar to what users encounter on many websites, such as "Sign in with Facebook" or "Sign up with Google." Typically, when users click on these buttons to log in, a login dialog opens, and upon successful login, they are redirected back to the website with a logged-in status.
As per our understanding, there doesn't appear to be an official way to achieve this with Oculus accounts. The closest option seems to be the "Account Linking" flow. Consequently, every time users click on our web portal's "Login with Oculus" button, they are redirected to the Account Linking page. It works, but the repetitive "Connect account" prompt seems counterintuitive, given that users have already accepted the account connection.
I am left wondering if our understanding of the "Account Linking" flow is correct? Moreover, are there alternative solutions or best practices for implementing an OAuth "Login with Oculus" flow that provides a smoother user experience?
02-21-2024 03:20 AM - edited 02-21-2024 03:23 AM
After reaching out to Meta support, we came to understand that the "Account linking" flow mentioned above is the only way to accomplish a "Sign in with Quest/Oculus" functionality. It is not ideal since it was not meant to support log ins (and prompts users to "Connect account" every time they want to log in), but it does work.
Here was their answer: "I don't believe the feature is meant for a 'Sign In with Quest' style functionality, but rather to attach a user to an account that you maintain on your own servers."
FYI: ShapesXR also uses the same login flow.