in our organization we have our own OpenId server (Identity Server) that we use to authenticate people into our applications, let me explain how we currently handle our web clients.
so we have an API that handles the authentication of users, the user calls an endpoint then they are redirected to the user's login page (on the identity server) and once they log in they are redirected back to the API (Authorization workflow + PKCE), the API sets an encrypted cookie on the user's browser that contains the access and refresh tokens, now the user is authenticated and any request they send has to go through the authentication API, which checks the cookie and attaches it to the request header then sends it to the desired upstream. As you can see, we don't trust the clients, which is why we store the access tokens in an encrypted cookie that only the authentication API can access.
okay so now how can we implement this on mobile devices? same as before we make an authentication API but instead of storing access tokens in an encrypted cookie we have to hand over the authorization tokens to the app, and the app will store and manage the authorization tokens, or we can keep them on the server and send back an id for the user, every time they send a request the send that id and the authentication API will handle managing the tokens.
but is that secure? what if someone stole the user's phone and got their hands on the user's authorization tokens? I've read that we should keep the tokens short-lived for better security but still, it is possible to do some harm during the token's short life. plus if they get their hands on the fresh token they will have access till the refresh token expires.
Are my concerns valid? what is the best way to handle this process on phones? the app is a very sensitive app with very sensitive data.