جریان Implicit یک جریان ساده OAuth بود که قبلا برای برنامه‌های بومی (native applications) و برنامه‌های جاوااسکریپت توصیه می‌شد که در آن سریعا بدون دسترسی به مرحله تغییر authorization code، access token به آن برگردانده می‌شد.
استفاده از روندImplicit به دلیل خطرات ذاتی بازگشت access tokenها در یک تغییر مسیرHTTP، بدون دریافت هیچ گونه تاییدیه‌ای از طرف client، توصیه نمی‌شود. (بعضی از سرورها این جریان را به طور کامل ممنوع می‌کنند.)
Clientهای عمومی‌مانند برنامه‌های بومی (native applications) و برنامه‌های جاوااسکریپت اکنون باید از روند authorization code با افزونه PKCE به جای آن استفاده کنند. همچنین مستند The OAuth 2.0 Security Best Current Practice در مقابل استفاده کامل از جریان Implicit و OAuth 2.0 برای برنامه‌های مبتنی بر مرورگر، روش استفاده از روند Authorization Code با PKCE را به جای آن توصیه می‌کند.
شکل زیر روند Implicit را نشان می‌دهد. این روش مشابه روش Authorization Code است با این تفاوت که در روش Implicit، بلافاصله پس از لاگین کاربرAccess Token به سمت کلاینت ارسال می‌شود. از این روش در Single Page Applicationsها یا SPA مثل انگولار یا React یا Vue.js (نرم‌افزار‌هایی که از فریم ورک‌های جاوااسکریپت استفاده می‌کنند) استفاده می‌شود چرا که امکان محرمانه نگه داشتن client_secret وجود ندارد.
اولین تفاوت هنگام redirect شدن به Authorization Server مشاهده می‌شود. مقدار پارامتر response_type از code به token تغییر یافته است. این بدین معناست که نوع پاسخ سرور به جای authorization_code، بایستی بلافاصله access_token باشد.
در این روش مراحل کمتری نسبت به روش Authorization Code برای لاگین کاربر طی می‌شود اما در عین حال به علت طی شدن مراحل ثبت‌نام در مرورگر امنیت کمتری دارد. مثلا token ردوبدل می‌شود در حالی که در روش Authorization Code به این صورت نیست و token بین درخواست‌های سرورها منتقل می‌شود بنابراین دسترسی یا اختلال در آن بسیار دشوارتر است.
بر اساس شکل ، مراحل انجام کار به صورت زیر خواهد بود:
· کلاینت درخواست Authorization را از طریق مرورگر به سرور ارسال می‌کند.
· در صورتی که کاربر درخواست را تایید کند، به سرور هدایت شده و لاگین می‌کند.
· در این مرحله همان‌طور که پیش‌تر ذکر شد، Authorization Server بلافاصله Access Token را صادر می‌کند و کاربر را به همراه Access Token به مسیر redirect_uri می برد.
· کلاینت از طریق redirect uri، Access Token را حفظ می‌کند.
· در انتها Access Token به کلاینت پاس داده می‌شود.
در این روش کلاینت هرگز احراز هویت نمی‌شود و این تفاوت قابل توجه این روش با سایر روش ها می‌باشد و Access Token ی که در این روش به دست می‌آید از نوع bearer می‌باشد که بین 5 تا 30 دقیقه اعتبار دارد و می‌توان از آن برای دسترسی به API ها استفاده کرد.
همچنین در این روش Refresh Token وجود ندارد و در صورتی که کلاینت به Access Token جدیدی نیاز داشته باشد، باید دوباره احراز هویت کاربر انجام شود.