But I wonder if I have to exactly follow the flow shown as follows:
To be more specific, is it possible to store customers email, password directly to Roku cloud and device registry instead of storing access token?
It's still adhere to the criteria "Channels must complete account sign-ups and sign-ins on the device using On-device authentication, without visiting an external webpage"....
We too have this issue.
So now we can't use Oauth2.0 Device Flow or Auth Code flow ? All Idp we use to authenticate our users using Oauth2.0 are not supported on Roku.
You can use the client credential oAuth 2.0 flow to get an access token and store it in the Roku Cloud. You can then subsequently get a refresh token upon validating a subscription and then store it in the Roku Cloud.
Hi @RokuJonathanD , I read your comment above and wondered if I've been missing something big - our interpretation of the new rule is that it prevents any kind of 3rd-party login so we're basically ditching 1/3 of our users in the next release of one app. Communication from RPS has aligned with this viewpoint, we've been advised to make changes to our infrastructure to enable Facebook (etc) users to convert to "real" username/password accounts on the service - but there are so many third parties involved and no non-Roku business case for doing it that it's not going to happen.
Reading about the "client credential oAuth 2.0. flow", it's described as:
The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. This is typically used by clients to access resources about themselves rather than to access a user's resources.
I don't yet see how it helps us authenticate a user of our service, could you give some further hints?